fr_stringtable

Discuss, plan, and make Translations for FreeOrion
Message
Author
User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: fr_stringtable

#241 Post by Dilvish »

Ouaz wrote:[key][space][space][#][space][translated] : that's right? (two spaces needed before #)
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.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: fr_stringtable

#242 Post by Cjkjvfnby »

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

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: fr_stringtable

#243 Post by Dilvish »

Cjkjvfnby wrote:...On updating file I copy header as is...
Could you explain this part more?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: fr_stringtable

#244 Post by Cjkjvfnby »

Dilvish wrote:
Cjkjvfnby wrote:...On updating file I copy header as is...
Could you explain this part more?
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.

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
This is header after my script works. For en.txt it is ends after 'common' section.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: fr_stringtable

#245 Post by Dilvish »

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

User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: fr_stringtable

#246 Post by Cjkjvfnby »

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.
Here end of parsing header:
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

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: fr_stringtable

#247 Post by Dilvish »

So, it looks to me like the beginning of make_copy() considers

Code: Select all

#APPNAME
#FreeOrion
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

Code: Select all

#KEY
#VALUE
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

Code: Select all

#KEY
#VALUE
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)
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: fr_stringtable

#248 Post by Dilvish »

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

User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: fr_stringtable

#249 Post by Cjkjvfnby »

Dilvish wrote:so, did this work out for you?
Work fine.

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

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: fr_stringtable

#250 Post by Dilvish »

Cjkjvfnby wrote:PS. Is it issue that value have space after closing triple quote?
The parser does not mind if there is whitespace after the closing triple quotes and before the newline.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Ouaz
Dyson Forest
Posts: 232
Joined: Wed Aug 13, 2014 7:21 pm
Location: France

Re: fr_stringtable

#251 Post by Ouaz »

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:
peace_proposal.PNG
peace_proposal.PNG (8.13 KiB) Viewed 9788 times
peace_translation.PNG
peace_translation.PNG (12.88 KiB) Viewed 9788 times
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)
first_AI_message.PNG
first_AI_message.PNG (12.2 KiB) Viewed 9788 times
I release every updated file under the CC-BY-SA 3.0 license.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: fr_stringtable

#252 Post by Dilvish »

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, 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.
I think it didn't as the first message (difficulty setting) is not translated too (but this is not a big deal)
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.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
LienRag
Cosmic Dragon
Posts: 2103
Joined: Fri May 17, 2019 5:03 pm

Re: fr_stringtable

#253 Post by LienRag »

Rayons gammas pour Death Rays, ça surprend un peu non ?

User avatar
Ouaz
Dyson Forest
Posts: 232
Joined: Wed Aug 13, 2014 7:21 pm
Location: France

Re: fr_stringtable

#254 Post by Ouaz »

LienRag wrote: Sun Apr 18, 2021 9:15 pm Rayons gammas pour Death Rays, ça surprend un peu non ?
Salut!

Ben... Imagine "Rayon de la Mort" ou "Rayon Mortel", ça ne sonne pas très bien :D.

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)
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.
De plus, ça permet de bien graduer les types d'armement pour les astronefs:

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.

Post Reply