Created attachment 744766 [details] Screenshot showing this problem Description of problem: If a translated string does not have the same conversion specifiers in the source string, saving it fails with the error which says "The expression '%e' is not present in the translation". I've attached a screenshot showing this problem. Please refer to it. I think translations like that should be accepted. Some format strings like date-time formats does not always need to have the same specifiers in the original texts. Version-Release number of selected component (if applicable): N/A How reproducible: Always Steps to Reproduce: 1. Open a string with one or more conversion specifiers on Transifex 2. Translate it into a string without the same specifiers 3. Press the save button. Actual results: Transifex says "The expression '%e' is not present in the translation" and translations are not saved. Expected results: Translations are saved normally. Additional info: A workaround is to upload a PO file instead of saving translations on the web interface editor.
Careful, this is very dangerous territory. We've had very bad problems in the past where translators have not maintained format specifiers. The result is the application will throw an error, possibly fully aborting. What makes this nasty is this will occur for one locale which had bad msgstr's with bad format specifiers. This presents a QE nightmare where the application has to be tested in every locale to make sure just one bad translation does not crash the application. To solve this problem we've written tools that analyzes every po file downloaded from TX to make sure substitutions done via format conversions are not lost or managled. I'm thrilled that TX has now apparently added consistency checks to prevent these problems much like we've been forced to do. FWIW our tools also enforce the use of named and/or indexed substitutions so that translators can reorder. I absolutely do not want translators unilaterally changing format specifiers. Translators generally do not have enough information and awareness of coding practices in each programming language to override the intentions of the original programmer. Any mistakes have the potential to crash the application.
Hi John, I know your point and partly agree with you about that check system is needed. But, when it comes to time formats, we sometimes need to change their specifiers depending on a target locale. For exmaple, the string ("%a %b %e %H:%M:%S %Z %Y") on the screenshot I attached, which is a time format for login history, is not applicable at least for Japanese. It would be better in the respect of UI if specifiers like that could be customized for target locales. How about warning translators about mismatching format specifiers and potential risks instead of rejecting them as error?
Time formats are a narrow case with issues unique to them. You have to be fairly smart to understand what you're looking at is a strftime format and how it's arguments are passed in different programming languages. Maybe the consistency checker needs to be aware of different formatting domains, i.e. printf, strftime, etc. and apply rules unique to that context. FWIW it's not entirely clear to me that strftime conversions should even be appearing in a msgid.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Output of LANG=ja_JP.UTF-8 date +"%a %b %e %H:%M:%S %Z %Y" 月 7月 28 17:39:38 EST 2014 Yes, it does cause confusing on Monday. Actually I would suggests that ask upstream to change it to "%x %X" or even "%c".
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.