That is my suggestion, yes. As far as the parser is concerned, the spaces are optional. But that spacing is standard for python comments, and python is the language Cj uses for these scripts, plus the whole reason it is standard for that language is because it is considered to improve readability, so that why I suggested it.Ouaz wrote:[key][space][space][#][space][translated] : that's right? (two spaces needed before #)
fr_stringtable
Re: fr_stringtable
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
Any ideas how to programatically detect end of file header? Current implementation finds first not commented line. It is line 13: https://github.com/freeorion/freeorion/ ... fr.txt#L13. On updating file I copy header as is and got duplicated #APPNAME.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
Could you explain this part more?Cjkjvfnby wrote:...On updating file I copy header as is...
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
Then I parse fr.txt, I find header to copy it as is to new file. After that I iterate other en.txt and put keys of en.txt to new file (commented of with fr.txt values). As result I got new file with translation and commented out untranslated strings.Dilvish wrote:Could you explain this part more?Cjkjvfnby wrote:...On updating file I copy header as is...
Here is new file:
Code: Select all
Français
#This is the French String Table file for FreeOrion.
#Traduction par alchemy, shivu, zareif, nilstilar et Ouaz. Traduction et amélioration en cours (04/2015). Version FR complète prévue pour release 0.4.5.
#################
# Common #
#################
#APPNAME
#FreeOrion
#APPNAME
#FreeOrion
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
Ok, I think I understand your intent now, and the basics of what you did. If you want to post (or link to) your script I'll see if any ideas come to mind.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
Here end of parsing header:Dilvish wrote:Ok, I think I understand your intent now, and the basics of what you did. If you want to post (or link to) your script I'll see if any ideas come to mind.
https://github.com/Cjkjvfnby/freeorion/ ... se.py#L113
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
So, it looks to me like the beginning of make_copy() considers to be part of the FR header and automatically includes it at the start of the result, without paying any more attention to its contents (this is the primary source of the problem). Then in parse(other_path) these lines just get skipped over (like all other commented-out-untranslated-keys). So later your code believes that the result does not have a APPNAME as a key yet, and so it adds the construction for it, causing it to be doubled up. I think that before you do all the processing on other and other_path, you need to determine the keys of EN, and then when you are checking for the other header you need to look for that construction and not include *any* such constructions in the header if they correspond to an actual key in EN. Or, at the very least, not include them in the header if they match the starting keys in EN (you could still wind up with them duplicated then, but it wouldn't be so glaring)
Code: Select all
#APPNAME
#FreeOrion
Code: Select all
#KEY
#VALUE
Code: Select all
#KEY
#VALUE
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
so, did this work out for you?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
Work fine.Dilvish wrote:so, did this work out for you?
Other trouble: my script remove all comments form fr.txt
This lines will be removed:
https://github.com/freeorion/freeorion/ ... .txt#L3642
https://github.com/freeorion/freeorion/ ... .txt#L8863
PS. Is it issue that value have space after closing triple quote? https://github.com/freeorion/freeorion/ ... t-11227613
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
The parser does not mind if there is whitespace after the closing triple quotes and before the newline.Cjkjvfnby wrote:PS. Is it issue that value have space after closing triple quote?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
Hi, it seems there is a problem with the translation of the Peace Proposals.
Although I translated them, the english strings from en.txt are displayed instead of the FR strings:
Last version of FO (June, 1st - 87b435c)
It's the first time I test the Peace Proposal translation in-game, so I don't know if it worked in the previous build.
EDIT: I think it didn't as the first message (difficulty setting) is not translated too (but this is not a big deal)
Although I translated them, the english strings from en.txt are displayed instead of the FR strings:
Last version of FO (June, 1st - 87b435c)
It's the first time I test the Peace Proposal translation in-game, so I don't know if it worked in the previous build.
EDIT: I think it didn't as the first message (difficulty setting) is not translated too (but this is not a big deal)
I release every updated file under the CC-BY-SA 3.0 license.
Re: fr_stringtable
Right, I hadn't actually tested the AI translations before, sorry. I'm glad that you did now. This resulted from the fact that until now the AI hasn't been reading in the config.xml optionsDB file; any options it needed were simply passed at the command line, and so it wasn't knowing it should use an alternate stringtable. Although I could have just added this to the command line as well, I decided it was time to start having it read the file, and the translations then work fine. It's committed now, so you'll see it in the next weekly build.Ouaz wrote:Hi, it seems there is a problem with the translation of the Peace Proposals. Although I translated them, the english strings from en.txt are displayed instead of the FR strings:
Right, it's intended that the bulk of this message remain in Latin. A small portion regarding aggression level could be translated, but that's mostly for debugging type purposes and I've left it as-is.I think it didn't as the first message (difficulty setting) is not translated too (but this is not a big deal)
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: fr_stringtable
Rayons gammas pour Death Rays, ça surprend un peu non ?
Re: fr_stringtable
Salut!
Ben... Imagine "Rayon de la Mort" ou "Rayon Mortel", ça ne sonne pas très bien .
Dans FO, il y a une certaine volonté d'utiliser des termes "technologiquement sérieux" (bon là, c'est vrai, Death Rays, pas vraiment).
De mémoire, lorsque j'ai repris la traduction il y a plusieurs années, les précédents traducteurs avaient opté pour Rayon Ultime, ou un truc du genre.
J'ai changé pour Gamma, en rapport aux Rayons Gamma en astrophysique, qui sont les rayons les plus énergétiques (https://fr.wikipedia.org/wiki/Rayon_gam ... ment_gamma)
De plus, ça permet de bien graduer les types d'armement pour les astronefs:Le rayonnement gamma de source cosmique résulte des événements les plus violents de l'univers : jets relativistes produits par des trous noirs supermassifs (blazars), sursauts gamma, etc. L'énergie des photons gamma émis peut atteindre des centaines de GeV.
Mitrailleur < Laser < Plasma < Gamma.
Ça fait partie de la liste des choses que je dois suggérer pour la version EN, mais comme c'est un changement mineur, c'est tout en bas de la liste. :p
En tous cas, merci pour le retour, et n'hésite pas à poster si tu as des suggestions de traduction.
I release every updated file under the CC-BY-SA 3.0 license.