--- In firstname.lastname@example.org
, Aubé Philippe
> I think we should bear in mind that :
> 1. All that is to be displayed should be translated.
That is why I'm trying to gather a list of what needs to be displayed
or output. While I can take a pass from what I see in the code and
character sheets, an exhaustive code search is time consuming, and a
few more sets of eyes and some experience with translation isn't
experience I want to ignore.
> 2. Everything that is to be displayed should not be used internally.
I disagree. There are some items (such as height) that could be
stored internally in arbitrary units, but converted to meters or
feet/inches only when displayed. This would require a database of
translations for meter, etc., but is likely preferable to forcing each
locality to translate "2 meters" into their local dialect.
> 3. There should be as few files as possible and the link between
> file and translation "holder" should be clear enough for everyone to be
> able to modify the translation easily.
...while at the same time not creating so much confusion for someone
creating a custom dataset that they have to do contortions to get a
personal dataset in only their home language.
> 4. Changing tags should not affect the translation.
> 5. Sorting should take into account accents.
A GUI and Output Sheet item, already FREQed, and outside the scope of
my current inquiry, but I agree.
> Let me be clearer on points 1 and 2.
> Spells have an awful long list of factors, most need to be displayed
> are used internally. There should be no such thing. The duration of a
> spell should be in two ratings : the duration as used internally and
> duration as displayed. Am I clear ?
I get the point; however, many of the spells items at the moment are
just Strings, so this isn't a concern.
> Maybe it would be a good idea to plit the files in several files : one
> file holding internal information, another one holding displayed
> information along with the translations (maybe one file per language).
> Each new PCGen version should simply modify the "internal information"
> part, not the translation one. When the translation doesn't exist, then
> the english displayed information should be used.
I think this is a bad idea, because it makes simple home-brew data
unnecessarily complicated by introducing multiple files. I believe
there are alternative solutions that do not require this complexity.
I'll explain more once I get a chance to dig up Aaron's previous
suggestions and make sure I'm not missing anything.