#8695 closed patch (outdated)
Support for translation prototype
| Reported by: | jvprat | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | GUI: Translations |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
I've been doing a prototype for messages translation based on the proposal written to -devel. I've separated it in 3 files just for readability. All three patches have to be applied in order to get it working.
translation-infrastructure.patch: It's what does the work. translation-marked-messages.patch: It marks several strings from the source code for translation translation-example-po.patch: It contains example translation files for catalan and spanish (just to test, not complete at all)
It's currently aiming at having a different font for each character set. If later there's a rework on the GUI to support unicode font rendering, the only change needed here would be to convert the po files to the desired character set.
As I said it's just a prototype to let you cast your opinions and rants about it. Here's the current status:
FEATURES: - can be disabled (no extra charge for small devices) - uses po2c to build a cpp file that contains the translations - no extra runtime dependencies - po files have to be coded in the character set of the GUI font - optional support for detecting locale language at runtime - optional support for converting messages to terminal character set (which can be different than the GUI one)
TODO: - add a GUI option to select the language in the misc tab - get a list of supported languages - change font when selecting a language (one can get the translation character set) - use configuration to use previously selected language ("" uses the system default) - mark all the translatable strings - change size of some GUI labels to let translations longer than the original
QUESTIONS: - which strings should be translated? All? Just the user-visible (excluding debugging and internal error ones)? - there are LOTS of debugging/internal error ones that will never be seen by the end user and will confuse translators
Please, let me know your opinions, both constructive and destructive ;) (if you prefer another approach)
Ticket imported from: #1739965. Ticket imported from: patches/800.
Attachments (6)
Change History (36)
by , 17 years ago
| Attachment: | translation-infrastructure.patch added |
|---|
by , 17 years ago
| Attachment: | translation-marked-messages.patch added |
|---|
Marks strings from the source code for translation
comment:3 by , 17 years ago
Some notes/questions/answers: * Please make sure to follow our coding guidelines (e.g. hugging braces in common/translation.cpp)
* There are spanish (?) strings in common/translation.cpp in the constructor
* Could you explain the different between _() and _t() ? This should be very very clearly documented, else people who write new code will use them incorrectly.
* Only the user visible texts should to be translated. The more strings we add to the list, the more work for translators, and the overall quality won't benefit either. For example, the "error" messages in gui/newgui.cpp are crypting to users anyway, so translating them serves no purpose.
* Overall, looks quite promising. Nice that somebody works on this.
comment:4 by , 17 years ago
configure result on my system:
Building translation support... yes (with runtime language detection, without terminal conversion)
The reason:
g++ ./scummvm-conf.cpp -o ./scummvm-conf -L/sw/lib -isystem /sw/include -Werror -g -ansi -W -Wno-unused-parameter /usr/bin/ld: Undefined symbols: _libiconv_open collect2: ld returned 1 exit status
Over here, -liconv is needed
comment:5 by , 17 years ago
The difference between _() and _t() is that _() is used to translate GUI messages, and _t() is used to translate terminal messages (it just adds a conversion). This is needed because both GUI and terminal doesn't always use the same character set (GUI will use the one defined on the translation, and the terminal will use the one defined on the locale).
Anyway I'm not very proud of this solution because it mixes concepts. A translated message could be sent both to the GUI and the terminal. The character set conversion should be done automatically when sending any text to the terminal, not just translations (for example when printing paths or user defined game names).
So... is there a common way to send text to the terminal where I could insert this conversion? Should I add it? With this, all translations could be done with _().
By the way, I've begun watching into the font rendering stuff and I thought it would be harder than it really is. I'll try to test how well does it interact with FreeType.
Thanks for your response.
by , 17 years ago
| Attachment: | translation-infrastructure2.patch added |
|---|
comment:6 by , 17 years ago
I'm attaching an updated patch. I've added the option to configure the language in the Misc tab. Currently you have to restart ScummVM to apply the new language. I'm working on a patch to do live update, but it will be a bit tricky (some widgets don't support changing their labels after being built).
NOTES FOR DEVELOPERS: - You have to mark the source strings you want to get translated. I've tried to mark most of the main ones, but haven't watched into engines and backends, and maybe I forgot some. This is how you should mark the strings after including "common/translation.h" (and adding the new files to po/POTFILES): - _() returns the translation in the GUI character set (without conversion from the translation file) - _t() returns the translation in the Terminal character set (does the necessary conversion if available) - _s() marks static strings to let the translators know about them, but doesn't translate them at runtime. Should use _() or _t() when using them. It's necessary because the configured language can be different when building the object than when the string is used. - common/messages.cpp should be distributed as part of the source code, in order not to add the perl dependency to generate it
NOTES FOR TRANSLATORS: - Add po/language.po taking po/scummvm.pot as a base - .po files have to be coded in the character set of the GUI font (currently only ISO-8859-1 is supported) - You can update and see the status of the translations using: make update-translations
NOTES FOR PORTERS: - It can be enabled by adding the "TRANSLATION" define at build time. - I've just tried it on linux. - Please let me know if it causes troubles in other platforms. - I've tried to use POSIX compliant functions for language detection and character set detection/conversion, but it may not work everywhere (it should be automatically disabled). You can add your own implementations if you want to add that functionality on other platforms.
TODO: - Live change of the language - Update the widgets' labels - Also change the font - Load character set dependent font or implement utf-8 rendering (I'll try with freetype) - po2c: don't use fuzzy strings
QUESTIONS: - I still think there should be a common way to send text to terminal (used by error, warning, something wrapping printf...) which would handle the charset conversion, instead of having it mixed with translation code. - How to translate these: gui/KeysDialog.h:39 gui/launcher.cpp:602 base/commandline.cpp: help string (by blocks? lines?) gui/about.cpp credits.cpp
As always, every comment will be welcome :) File Added: translation-infrastructure2.patch
by , 17 years ago
| Attachment: | translation-marked-messages2.patch added |
|---|
by , 17 years ago
| Attachment: | translation-example-po2.patch added |
|---|
comment:9 by , 17 years ago
| Owner: | set to |
|---|
comment:10 by , 17 years ago
I really should take a closer look at this soon, I just seem to lack the time... But everybody else is invited to review this, too :). The patch probably won't apply anymore, but this feature is still of interest. The main languages of visitors of our website, in order of frequency: english, german, italian, french, spanish, russian, dutch... It sure would be nice to have localized versions of ScummVM for some/all of these (and maintainers for them).
In addition, a translated website (well, at least *partially* translated: Navigation, gallery, the "What is ScummVM" blurb) would be nice, too.
And finally, some "international" subforums on the forums, maybe?
Eugene, what do you think?
comment:11 by , 17 years ago
I'll try to update the patch for current svn. I'll also try to put some time on the live update of the gui strings (haven't looked at it yet). What also remains to be done is the non-ascii font rendering, but I don't have any experience on that, so I'd be grateful to someone taking a look at this part.
About the global project internationalisation, I think it would be nice to create a guide on the wiki explaining how to adapt ScummVM to your language, beginning with translating the .desktop description, and adding other parts in the future (translating the .po files, the website...)
comment:12 by , 17 years ago
I can volunteer for the French translation of the website (and maybe ScummVM, giving the proper instructions).
comment:13 by , 17 years ago
OK, before this gets swamped by similar offers: We are currently *not* looking for translators. If we are at some point, we'll make sure you all will learn about it. In the meantime, there is no point in stating your willingness to translate here. Thanks anyway, though ;-).
comment:14 by , 17 years ago
Well, I always was all for adding ScummVM interface translations.
As of language-specific forums, the only concern I have is moderatorial.
comment:16 by , 16 years ago
Reminder: Both Sev and Fingolfin want to have a closer look at this... Now that 0.11.0 has been branched, it would be cool to start integration of this. Or reject it. Whatever -- but get to a decision :)
comment:17 by , 16 years ago
I talked about this with Sev a few days ago and redefined the requirements. My current implementation already supports live updates of the gui, but all the strings of all the languages are built statically inside the executable (it's what po2c does). Sev said it's unacceptable because it isn't scalable for low memory devices, and he proposed to have external packages (like the ones for the themes) which can be loaded at runtime and that optionally contain the needed fonts for that language's codepage. This needs extra work in the generation of the packages and the loading part, and I won't have time to work on this for about 3 weeks.
comment:18 by , 16 years ago
Nny news on that patch ? How can I use it on the new ScummVM version (0.11.0) ? Any manual ?
btw, I already translated two ScummVM versions ;) from the source... ouch...
comment:19 by , 16 years ago
You can not use this patch with 0.11.0, and there is no "manual" either. This is work in progress, and not yet ready for general use.
As for news: Jordi's last message reflects the current status precisely.
comment:20 by , 16 years ago
Er.... seven months later any news guys ?
A new version is about to come out, maybe it's already implemented ? :)
Thanks
comment:22 by , 15 years ago
Any news about this? Is it a candidate for the next GSoC? I can translate all the strings to Spanish.
comment:23 by , 15 years ago
Jordi, we really have to finish it. Do you have any plans? The patch looks really cool, and if we only would load the .po files on the fly, that would let us finally commit it.
comment:24 by , 15 years ago
Sorry, I keep forgetting about this one. I'll try to update the patch next week, and will have a look at the runtime loading later, which will require to rework what po2c did.
comment:25 by , 15 years ago
"- po files have to be coded in the character set of the GUI font"
This sounds like we would want to consider switching to some defined charset in our whole codebase, like LATIN-1. Was there any decision on that yet?
comment:26 by , 15 years ago
No, the intention was that there could exist several packs of the GUI fonts with arbitrary encoding in them. Like, use Win-1251 encoding for Russian, provide Russian font and messages as a translation pack.
comment:27 by , 15 years ago
It would be nice if we would have some common input (thus the ascii part of the KeyboardEvent part), so game having both original GUI and using the ScummVM GUI could convert the string encoding between the GUI and usually DOS, so the savegame names will display fine in both cases. Of course we need a defined charset in our fonts for that.
Also OSystem::setWindowCaption requires the data to be passed in LATIN-1. Thus even if we have a translated GUI it would be hard to cope with translated game descriptions in the launcher. Of course that is a separate issue, but having no common GUI font charset will make this much harder.
This all makes a totally custom GUI font charset of course problematic, thus I'm asking how this is supposed to work.
comment:28 by , 14 years ago
| Resolution: | → outdated |
|---|---|
| Status: | new → closed |
comment:29 by , 14 years ago
This patch is out of date. Another patch was used for implementing the feature.
comment:30 by , 6 years ago
| Component: | → GUI: Translations |
|---|
Translation core