QUOTE (Nebular @ Sep 7 2011, 07:25 PM)
The problem is that Chummer relies on some of the English strings in the data files - usually just Category, but it does look for a fragment in an item Name. For example, Cyberware Grades are explicitly tied to the English strings, some Gear information is determined based on its English Category and so on, so while simply translating things
would work, it would also break stuff in the background and cause some numbers to not add up correctly.
I don't know how you programmed it but I do know the golden rules of translation programming :
read, write, affich are three different use of a variable.
Here's how I'd do :
1 - (no change) - When Chummer have to write in files, it does using the english words.
2 - (if not stored in RAM, no change) - When Chummer have to read, it reads using english datafiles.
3 - (changes are here) - When Chummer have to affich, it convert from english to the translation setting (get the english word as usual, cross-read in some new translation files we have to make, affich what's been read there or the english name if not found).
You will spot the #3 change each time you call the UI's display boxes. There may be loads of work in listboxes but I'm not sure if i rememebr well C++ windows API (from 10 years ago, sorry
).
That way :
- .chum are still in english when you read it whatever the language is
- .xml (datafiles) also
- what's created by the english can be read by the french/german and vice versa
- what's been created by the french can be read by the german and vice-versa
- you can update english datafile details without changing that much translations, provided you don't change the names.
You also should ask yourself what are the details that are region-specific. What I see for now is names, category, books and pages.
You also must be aware that makes Chummer use more I/O operations (or 2 per item if you stored translation in RAM at reading) at affiching but if we have this in our language, I think we'll not care
What you can do also is :
- when you read from english files,
==> IF the language selection is not english, find the translation in appropriate translating files
====> IF FOUNDED then store these values in Translated[name of the usual value]
====> ELSE store english in Translated[name of the usual value].
==> ELSE store english in Translated[name of the usual value].
With what I said about step 3, affiching, each time you call the UI you change the name of the variable to drop in the UI by Translated[name of the usual value].
If you want to accelerate translating readings, you can generate a translation index (for example you add a quality under each name in your datafiles, like this :
<name>EDG</name><quality>attribute abreviation</quality><translateIndex>42</translateIndex><page>96</page><book>SR4</book><cost>1000</cost><avail>12F</avail>
In the french version of the xml, you'll have
<translateIndex>42</translateIndex><name>CHA</name><quality>abreviation d'attribut</quality><page>92</page><book>MdO</book>
And no bonus, no cost, no avail etc. The english datafile provide this for the french translating file. The french translating only is to affich the names of those items.
Now, for Edge, the exemple is stupid (MdO refers to the french version of Street Magic) but you get the idea...
QUOTE (KeyMasterOfGozer @ Sep 7 2011, 06:49 PM)
I want to let you know, we really appreciate the effort.
Indeed !
BTW, I think there's load of guys willing to help in the french community. I know a few .net magician so maybe they could help you too.