[strawberryfield]

There are other strings that cannot be translated: the descriptions of keys in the options of menu.exe and in the help window of runactivity.

Could be available for translation in the future?

[James Ross]

strawberryfield, on 19 February 2014 - 01:01 PM, said:

There are other strings that cannot be translated: the descriptions of keys in the options of menu.exe and in the help window of runactivity.

Could be available for translation in the future?

If you mean the labels for the keys, they could be translated; the keys themselves cannot.

[gpz]

strawberryfield, on 19 February 2014 - 01:01 PM, said:

There are other strings that cannot be translated: the descriptions of keys in the options of menu.exe and in the help window of runactivity. Could be available for translation in the future?

The key names are currently generated from enum key names, which method is inadequate for localization. String descriptions need to be added for them first, but they are unavailable yet. So in the future yes, but now not. :)

[strawberryfield]

gpz, on 19 February 2014 - 02:03 PM, said:

The key names are currently generated from enum key names, which method is inadequate for localization. String descriptions need to be added for them first, but they are unavailable yet. So in the future yes, but now not. :sign_rockon:

I searched that strings in the code but I didn't find them. Now I know why.
Thank you.

[James Ross]

Peter, I'm not sure I understand what you're up to in X2047. There is no project nor assembly called ORTS so why is that the name of a localisation file? My preferred arrangement is that every project/assembly (should be the same thing) has one localisation file and that's all there is. That means MSTS.Formats, MSTS.Parsers, ORTS.Common, ORTS.IO, Menu and RunActivity.

[gpz]

The problem is the files in Source\ORTS\ directory are not in Menu directory, and not in RunActivity directory, thus they are left out completely from localization. That's why I had to add one more call to Menu.csproj post-build step.

Just look at it: Menu post-build call only scanned the Source\Menu directory, RunActivity post-build call only scanned Source\RunActivity, ORTS.Common post-build call only scanned Source\ORTS.Common, etc... Neither of them scanned Source\ORTS.

(Please note: xgettext parses source files for localizable strings only on file level, searching for some keywords, like e.g. GetString("blabla"), it doesn't understand the project structure set up in .csproj files.)

An alternative would be to pass more directory names to be scanned by xgettext, which could be referenced like this: xgettext -D %dirOne -D %dirTwo . This is how it was set up before your mods.

[Serana]

I agree with Peter. The ORTS folder is shared between Menu and RunActivity, so it should have it's own localization file.

But, since the code is shared, could it be moved to a library project ?

[James Ross]

gpz, on 20 February 2014 - 11:05 PM, said:

The problem is the files in Source\ORTS\ directory are not in Menu directory, and not in RunActivity directory, thus they are left out completely from localization. That's why I had to add one more call to Menu.csproj post-build step.

Just look at it: Menu post-build call only scanned the Source\Menu directory, RunActivity post-build call only scanned Source\RunActivity, ORTS.Common post-build call only scanned Source\ORTS.Common, etc... Neither of them scanned Source\ORTS.

Oh, yes, of course. This won't last though...

Serana, on 20 February 2014 - 11:28 PM, said:

But, since the code is shared, could it be moved to a library project ?

Yes, it should move somewhere. Soon all code will be in a directory structure that matches the project structure. :lol2:

[Serana]

I don't know what happened, but PO files were converted from UTF-8 to ISO-8859-1 which did a mess on all accentuated characters.

[gpz]

After checking the fr.po file on my computer, I see it still is in UTF-8 format. Which string would be a good one for checking?