App: Create addTranslatableExportType method #18678
Conversation
This method aims to solve the problem of untranslatable description strings on file types. Some, but not all, file format description strings contain translatable elements. For example, some languages may translate "FEM mesh formats". Many format descriptions include the words "file," "format," or "mesh" -- these could potentially be replaced with localized versions. There are two challenges: the first is to prevent translators from accidentally breaking the quite-sensitive formatting of the list of supported extensions. This is achieved by dropping anything that looks like such a list from the string post-translation, and simply recreating it in a known-good format from a list of extensions provided to the new method. The second challenge is to support retranslation during a single run of the program (e.g. changing the language of the UI while it is running). To achieve this, a caching system is used. Every call to the new method is cached, and when the language changes those calls are "replayed" both to remove the original entry, and to add the entry in the new language. This commit implements the Export method and cache, but does not add either the corresponding Input method and cache, the replay of the cache, or the actual code update needed to call this method when a translation is possible. Unit tests for the new method are added, and some refactoring of a small set of existing tests is included as part of the reorganization of the Application class tests.
github-actions
bot
added
the
Mod: Core
Originally this test file simply defined the appropriate macro, but since macros leak that can have unexpected side effects on other tests. It's safer to simply only run that test on the Mac.
|
Is the approach to remove the parentheses and to add them again? If translators are so unreliable, would it be better to translate without extensions and append them later ("Some type (%1)")?
|
My thinking was that by providing the whole string, it would give translators more information about what they were translating -- for example, that "FEM mesh formats (*.dat *.inp *.med *.stl *.unv *.vtk *.vtu *.z88)" would be better for translators than just "FEM mesh formats". But maybe your suggestion is enough for translators, using "FEM mesh formats (%1)" -- @kaktusus what do you think? (And it's not that I think all translators are unreliable, but I suspect there will be some temptation to do something like, e.g. add commas to the list, which will break it).
Yes, I'll change that. |
|
@chennes can this information be provided as an extra-comment to the translators instead? |
|
Yes, as long as we are OK with doubling the lines of code needed to specify an export type: the syntax for those comments adds another line. It is probably preferable to the current duplication, but it isn't clear to me what exactly will help translators the most. |
|
@chennes I'm trying to see how extra-comments looks in Crowdin, but I'm having trouble locating a |
|
I don't think we'll be able to find the perfect solution to a problem that doesn't exist yet. I would start with adding extracomments, depending on what we write, that should be enough. |
|
Agree with the comments above! |
|
Sorry chennes you waited so long for my answer. I posted this topic on the forum in the translators section. Maybe someone will also write something interesting. |
NOTE: This is a work-in-progress, but I am sure there are already some things that could be improved, so I am looking for feedback particularly as regards the C++ aspects of this PR. Especially have a look at the way I've written the two string manipulation functions. I played with
std::transformandboost::join, but I didn't feel like that made the code any clearer, but it definitely feels like there's a better approach (or maybe that's the Python programmer in me...). Suggestions welcome! Pinging @xtemp09, @jbaehr, @hyarion, @kadet1090 , and anyone else interested. Also, @yorikvanhavre does this seem like a reasonable approach to the problem?This method aims to solve the problem of untranslatable description strings on file types. Some, but not all, file format description strings contain translatable elements. For example, some languages may translate "FEM mesh formats". Many format descriptions include the words "file," "format," or "mesh" -- these could potentially be replaced with localized versions.
There are two challenges: the first is to prevent translators from accidentally breaking the quite-sensitive formatting of the list of supported extensions. This is achieved by dropping anything that looks like such a list from the string post-translation, and simply recreating it in a known-good format from a list of extensions provided to the new method.
The second challenge is to support retranslation during a single run of the program (e.g. changing the language of the UI while it is running). To achieve this, a caching system is used. Every call to the new method is cached, and when the language changes those calls will be "replayed" both to remove the original entry, and to add the entry in the new language.
This commit implements the Export method and cache, but does not add either the corresponding Input method and cache, the replay of the cache, or the actual code update needed to call this method when a translation is possible.
Unit tests for the new method are added, and some refactoring of a small set of existing tests is included as part of the reorganization of the Application class tests.