I have just started doing some Transifex translation for an altcoin forked from Bitcoin 9. Here are some challenges and observations with a focus on the Qt application:
1 - The string resources can be categorized into four groups for the purposes of the following:
1.1 - Plain literal strings.
1.2 - Strings with embedded markup (e.g. ...
1.3 - Strings with embedded C style printf formatting directives (prefixed with %).
1.4 - Strings with embedded alt key accelerator code flags (indicated by &).
2 - This presents the following challenges to translators:
2.1 - Longer translated strings may unknowingly end up being truncated in the UI - addressed by testing, but makes UI changes and redesign delicate with testing x N languages required.
2.2 - Translators mush be aware to some degree of the manner in which the various formatting directives are used i.e. translators must to some small degree be either coders or trained software translators. Casual translators tend to mess things up in a number of different ways.
2.3 - I don't believe it's appropriate to put formatting directives into string resources. If the developer wishes to change a format, is he/she to make the change to every separate language resource ? This is a maintenance nightmare. This is too tightly coupled a connection between the core code and the language resources. imho the solution is to split such string resources into segments without formatting directives and keep latter in the source code.
2.4 - Regarding alt key accelerator codes e.g. O&ptions will display with an underscore under the p [after Alt is pressed] to indicate that the menu option / dialog control can be invoked by the keyboard accelerator Alt-p, with p chosen rather than o because Alt-o is presumably already taken for an adjacent menu option / dialog control having concurrent run-time focus. Note that you can have clashes across different menus / dialogs because they don’t both have focus at the same time. This point is quite challenging for translators because not knowing the complete context of where each specific string resource is used (possibly multiple uses) it is difficult to avoid the possibility of multiple translated strings resulting in accelerator code clashes. There is a need therefore for some documentation that groups string resources used as menu/dialog labels so that translators can more easily select their alt key accelerator characters to best effect and avoiding clashes.
I have not yet looked to see if these same issues exist with the latest Bitcoin version, but I can imagine that with more important priorities elsewhere, not much has changed from 9 -> 11/12. I would be more than happy to contribute towards working out and implementing a solution to some of these issues. But being relatively new to looking under the bonnet of the Bitcoin code base (all be it via a forked altcoin) I thought it best to place these observations here to start with.
Apologies if I'm stepping on anyone's toes, but I think you guys have pretty thick skin by now.
Henry
Topic: String Resources & Embedded Formatting (Read 475 times)
Jump to: