Chimel31
2nd March 2012 09:22 UTC
How to really help translating
Hi,
Is there some guide on how to help translating?
All I can see is these 2 ANSI (?!?) language files, nothing like the open source Launchpad interface.
Here's for instance the status for all languages on the Miro vidcast player:
https://translations.launchpad.net/d...emocracyplayer
Launchpad allows the localizers to translate either directly on the web site, or upload and edit the whole set of translations with a PO file editor. In both cases, both the original English string resource and the translation are visible simultaneously. I was wondering if there was a similar way to translate NSIS, since the files are monolingual. Like a tool that would upload both the English and one or more localized files for side by side comparison, for instance.
Chimel31
2nd March 2012 21:19 UTC
I'll write down some of these issues I meant to fix but don't know how.
Localization issues:
1) In French.nsh, replace:
!insertmacro LANGFILE "French" "French"
with:
!insertmacro LANGFILE "French" "Français"
French is the only language name that appears unlocalized at setup, most other languages have this second language name entry localized in their NSH file.
2) In French.nsh, remove the extra space in:
${LangFileString} MULTIUSER_INNERTEXT_INSTALLMODE_TOP "Choix entre installer $(^NameDA) seulement pour vous-même ou bien pour tous les utilisateurs du système. $(^ClickNext)"
It doesn't show on this web page, but there are actually 2 spaces instead of 1 between the 2 words in bold.
Localizability issues:1) In the NLF file, it seems that the components size displayed in custom setup is a runtime concatenation of the resources "B" and "M" (for byte and mega) at the end of the file. This just doesn't work for many languages. For instance, there is no single letter "B" abbreviation for French (at best it's abbreviated as "oct"), a space separator also needs to be inserted between the number and the unit, and some languages may use the K, M, G multipliers in a different way, maybe before the number.
I suggest to replace the 4 US-centric resources "B", "K", "M" and "G" with localizable resources "
%placeholder%B", "
%placeholder%KB", one for each unit.
For French, these should be localized as "
%placeholder% octets", "
%placeholder% Ko", etc. (Using the appropriate syntax for numeric placeholders, of course.)
And who knows, maybe some languages localize "KB" as "BK"...
2) Merge the 2 NSH and NLF files into a single file with a single format, it would considerably help localization. Only if you intend a major update to the product, otherwise it wouldn't make sense.
3) Localization toolset: I can't seem to find a way to be sure that the language files are in sync with the English files. Are localizers using some specific tools, how are the new and updated text resources exposed to localization. Do we need to retranslate from scratch when a resource is updated? (if the translation is replaced by the new English text) The files are also monolingual, is there a tool to view both the English and localized text?
Is there a way to check out a file or resource, to indicate other contributors that we are working on them?
Globalization issue:Both NSH and NLF files are in ANSI, which does not suit localization.
The files should be in Unicode encoding, so Unicode-only languages can be localized, or to allow a localizer to consult other languages' translations from the same code page, or to allow running setup for a given language even if it does not match the main computer language.