OndrejR wrote:I think that better idea than do it in game is to program convertor to do such thing. Currently in svn there are old translations(Spanish, Dutch, French) which are outdated. Before every release(or before someone want to translate) someone can run this convertor to fix translation automatically on all translations. If there is something missing or number of parameters don't match, then there will be added original english text. Also ordering will be same as in English text. And if some text is not needed anymore, then automatically it will be forgotten.
There are some issues with doing this automatically out of game.
Assume you have a program that reads the english stringtable and a translation, and replaces all the strings in the english table with the corresponding entries in the translation. The resulting mixed translation stringtable is written to a new updated translation file, which the game can load.
This works fine for adding strings or removing strings. Any new string added to english gets copied to the translation unchanged, and any removed string from english isn't substituted with the old translated version when running the program.
It also works for updating translations by editing the files to replace untranslated strings with translations. Any changes will be retained when running the program.
But how should changes to the english stringtable be handled if they're not additions or removal of strings? Pure text changes occur, in which a string is rewritten, and sometimes parameters in strings are added or removed.
If nothing special is done, the program that blindly replaces the english stringtable with entries from a translation will end up replacing newly changed english strings with old versions of english or the translation language that are in the translated stringtable, thinking it's copying a translated string over the different version in the english file.
The program could check changes between versions of the english stringtable. If an english string is changed in any way, the program could discard any translated version of that string and just output the english. This is potentially annoying for the translator, especially for trivial changes to the english file that don't change the meaning or any assumed formatting, but this would probably be safest.
Presumably some sort of marking of strings in the translation with comments could help, indicating that the string was translated but rejected due to a change in english, and what the rejected version of the translation was...
The program will need to preserved comments in the translation file, then, and copy them to the updated translation. But this is probably more difficult than it seems.
If comments from the translation are copied into the updated translation by the program, then it can't also copy comments from the original english translation. Otherwise, there'd be no way to tell which file a particular comment line came from, and whether it's already in the translation, or if it's changed, or if it's new and needs to be copied.
Strings also move around within the stringtable sometimes. Which comments should be associated with and moved with which strings? It could be the comments before a string in the english file or the translation, which would be placed before that string in its new location within the updated translation... This might make problems for section headings or similar comments, though, which would be harder to associated with a particular stringtable entry.
Later maybe there will be GUI for this or online site. Old site(FOOT) with translator is not working anymore and on this site they weren't considered updates from svn(or periodically integration with svn).
It's easy enough to get the latest version of the stringtable from SVN. There is web access, so any program with web access (regardless of whether it has a web interface) should be able to download the latest
eng_stringtable.txt periodically or upon request.
If I sometime wanted to do such thing(I am from Slovakia and this language witch Czech(which is related language) currently is unsupported in FreeOrion), then it have to be written in high level language such as Python or Java. Do it in C++ or in PHP is pain for me.
A web interface would be ideal, as it greatly lowers the barrier to entry for translation contributions. Having to get python running and (I assume) running a command line program isn't that helpful. Java, if has to run in a little java applet box thing, wouldn't be very good either. Ideally the web-based translation tool would use actual web interface widgets and links to navigate.
Problem with hosting is solvable with some freehosting(Python and Java), but question is if it shouldn't be more official.
Any program written for translation should be hosted on freeorion.org, so we can maintain it. Disappearance of enthusiastic but temporarily volunteers offering hosting elsewhere makes them of limited use. The FOOT creator is such a case, despite the apparent utility of his tool, while it existed.