Translation into other Languages

A little tutorial, in case of:

In the "encode" menu, they're two part: encode and convert.

1) You have an ansi file (encoded in ansi in checked)

2a)If you click on "encode in utf-8", it change the encoding, your dicritic is messed up because it's always in ansi.

3b)If you cick on "convert in utf-8", it change the encoding in utf-8 and convert all diacritics from your ansi-coding to the utf-8 one, so all diacritics are converted. No further work to do.

note:
Utf-8 bom: it's 2 byte in front of the file to say "hi! i'm an utf-8 file!" but some/most of program don't recognize it, and it can create bugs.

I haven't tried that way, but definitely changing ANSI to UTF do the trick. Original xml files are encoded in utf-8 without bom, whatever it means. It took me a while to test it.
 
This is the csv file I'd use for translating CP(current version) http://forums.civfanatics.com/downloads.php?do=file&id=24863. It's easy to open in any spreadsheet program.

No it isn't. Specially Excel has problems with csv, more than ever when it's not Comma Separated Values but as in this case Tab-separated.
Simple opening it with excel concatenates the whole text of the line in the first cell. When you open it with excel and save it without having changed anything, all is a mess:
This
Code:
Tag	en_US	es_ES
with the tabs separated as in your template, becomes (in Germany)
Code:
"Tag	en_US	es_ES	";;
because Excel usually does not recognize TAB as separator when opening a file and uses (language dependent) comma or semicolon as separators when saving it.

Another problem with csv is when the text contains the separators itself. I guess that's why you used tab as separator, hoping it is not used in the text. If it is, there's trouble.

When the text has multilines, it needs to be surrounded by quotation marks. If a text has many lines and quotes, there's trouble.

I like the idea of having a central file, but csv is not the adequate format. It looks easy at first, but then turns out to be unusable.
 
No it isn't. Specially Excel has problems with csv, more than ever when it's not Comma Separated Values but as in this case Tab-separated.
Simple opening it with excel concatenates the whole text of the line in the first cell. When you open it with excel and save it without having changed anything, all is a mess:
This
Code:
Tag	en_US	es_ES
with the tabs separated as in your template, becomes (in Germany)
Code:
"Tag	en_US	es_ES	";;
because Excel usually does not recognize TAB as separator when opening a file and uses (language dependent) comma or semicolon as separators when saving it.

Another problem with csv is when the text contains the separators itself. I guess that's why you used tab as separator, hoping it is not used in the text. If it is, there's trouble.

When the text has multilines, it needs to be surrounded by quotation marks. If a text has many lines and quotes, there's trouble.

I like the idea of having a central file, but csv is not the adequate format. It looks easy at first, but then turns out to be unusable.

I use LibreOffice Calc, and it opens and saves it fine, just have to remember to unselect commas; I haven't tried opening the file in Microsoft Excel. Yes, I use Tabs because no text has any tab, so far, and if it ever has, it can be replaced with spaces.

I have thought of csv because they are more script friendly, but if it becomes too difficult, we may use a more common spreadsheet format. Then I'd advocate an open format like ods.

PS: I believe there is a 'Text Import Wizard' in Microsoft Excel that allows importing tab separated csv files. You need to open it from File->Open->Text File menu.
 
If you guys are seriously considering using a spreadsheet to manage these files you really should create an online version like Google Spreadsheets. It is far easier to work collaboratively on an online file than to download and edit it and then re-upload it.
 
If you guys are seriously considering using a spreadsheet to manage these files you really should create an online version like Google Spreadsheets. It is far easier to work collaboratively on an online file than to download and edit it and then re-upload it.

I don't only consider it seriously, I think that this is the only way to keep language support maintained. I was considering github, but google may do.

Github offers control of what is published with its branching method. It prevents someone touching something that should be left untouched. Good if there are several people working in the same document.
Google is simpler, no action from the project leader is required, and no need to install any program. Good if there is only one translator for every language (which may be the case). Google Spreadsheet offers to save in ctv format (tab separated), so it's a plus.

ExpiredReign, you've convinced me!
 
I don't only consider it seriously, I think that this is the only way to keep language support maintained. I was considering github, but google may do.

Github offers control of what is published with its branching method. It prevents someone touching something that should be left untouched. Good if there are several people working in the same document.
Google is simpler, no action from the project leader is required, and no need to install any program. Good if there is only one translator for every language (which may be the case). Google Spreadsheet offers to save in ctv format (tab separated), so it's a plus.

ExpiredReign, you've convinced me!

That being the case you might want to look at the link I made earlier to the Communitas spreadsheets.
Even if you remove all the Google translation code and just keep the actual text you will see that you don't need to save the output into anything, simply highlight a column and copy/paste into the editor of choice and save it there.
You set it up so all the needed XML or SQL code gets added to each column and the translators don't have to worry about any of it. This ensures no-one messes up the game code and only the actual text in each language is exposed to the translators.
 
I must admit this spreadsheet scared me the first time I saw it!

Now that I read it more carefully, it seems great. All files that need to be translated are in sheets inside the same file, so no file could be missed. Coding problems may be solved directly.

Is there a main host for the doc? I want to migrate what I've already translated to this. Or should I create it first for latest CPP?
 
Hands on, it's not an easy peasy. CP has only one xml text file, huge, but just one.
CBP has several texts, some in a folder, some in modules folders, some are xml and others only sql. I haven't been able to find CSD text files, only something in german. Sql files are harder than I thought, cause they're not so simple as LABEL-TEXT-GENRE, it also adds mod specific routes. Some xml files have definitions before actual text. I wonder how is someone going to rebuild these xml files with only the spreadsheet info. Texts in luas can't be helped.

Next issue is where to share. I have converted a couple of files into my google account. I don't know if I am the most suited to host the files, though. The file for CP can be seen here:
https://docs.google.com/spreadsheets/d/1HRHjihUDBqvhsvtvgfW24ivCjbGmYEGp5LVGGOjrtgQ/edit?usp=sharing
 
hey guys, im wondering if there is any german translation project already running at the moment. I feel like im able to contribute to it. Since im not understanding your messages about automatically translating, i can only offer to translate some file (like the sql ones of Balance Changes/Text/en_US) to german manually. The ones ive been translating yet are working fine for me. Or is it wasted efford due to your state of progress? Running projects can also PM me ;)
 
hey guys, im wondering if there is any german translation project already running at the moment. I feel like im able to contribute to it. Since im not understanding your messages about automatically translating, i can only offer to translate some file (like the sql ones of Balance Changes/Text/en_US) to german manually. The ones ive been translating yet are working fine for me. Or is it wasted efford due to your state of progress? Running projects can also PM me ;)

I dislike to translate a file that is going to change next month, without knowing what texts exactly are changing. Even more if the lack of translation of a single text can potentially break your game. Let me explain.

Those xml and sql use labels inside databases. Some texts are replacing existing labels, like a unique unit description, some other are new labels that don't exist in vanilla, like the zeppelin explorer unit description. When we install CPP, it's by default localized in en_US, and their files are saying "For language en_US, make this LABEL say this TEXT". When you have your locale game in German, CPP isn't adding or replacing any text to your database, because you aren't using language en_US. That's why you need to change every en_US for a de_DE, so those files do actually something to your game. You have experienced what happen when we don't replace the language setting: some texts exists already but they are from vanilla and aren't accurate, some other texts are just missing, but you can't know they are missing for most of them because there is no warning.

So, imagin that we translate a file and one month later there is a new file that removes 3 lines and adds 15 new texts. Try to find those lines just comparing new xml against the old one. Are the modders going to tell us exactly which lines they have changed? And evenso, what if we can't work on them for several months? What if we can only do a partial translation, would it be useless?

To fix all these issues, there are two simple rules:
1. Whenever a translation is missing, newest texts in english should be used.
2. Whenever a text is removed, replaced or added, it should happen to every supported language.

Point 1 will allow to play the game in other languages even if no translation is available, it just will have some texts in english, so it will only stop people that have no idea of english language. It will also allow to have a playable partial translation. It will also make possible to have a new playable version (even betas) that is not fully translated.
Point 2 will make language support manageable from version to version, as we may only need to check tens of texts instead of thousands.

Having all languages support in one single file is just to make it easier for modders, they only need to change one line in a single file for every mod instead of changing that same line in a file for each language supported.
 
okay well, if i got this correctly, id have to work on the file you uploaded as an example. Just adding de_DE in the column E and then translating into german below (as u did for spanish).

Thats how im able to contribute, right? If it is, id like to. Sounds great.
 
okay well, if i got this correctly, id have to work on the file you uploaded as an example. Just adding de_DE in the column E and then translating into german below (as u did for spanish).

Thats how im able to contribute, right? If it is, id like to. Sounds great.

I hope so. Active modders haven't confirmed that they are able and wish to work with this yet. Some files need additional work, I wasn't able to add sql files and some xml files have label definitions that I can't express in a spreadsheet. So maybe this file is not a final version. I've designed single files for every mod, and multiple sheets for every text file in a mod. But yes, ideally you only need to add a column headed by de_DE for it to work, and every line you translate will show in the german version.

To my knowledge, there are translations to russian and polish, but they are translated the same way you did before and somehow got lost. I don't want that to happen again. I consider myself quite lazy and I'd hate to do useless work.

Please, take a look at it, tell me if you see something that can be improved and help me convincing the modders to arrange their text files in a way that's more translator friendly.

EDIT:
This is the file for CBP, without sql files, and removing the definition part of xmls.
https://docs.google.com/spreadsheets/d/1rsfZZzm5t0vR4EUzJipvc-PluD78DSyJ_GUHgfPAlrA/edit?usp=sharing
Notice that there are several sheets, one for every text file in CBP.
 
I hope so. Active modders haven't confirmed that they are able and wish to work with this yet. Some files need additional work, I wasn't able to add sql files and some xml files have label definitions that I can't express in a spreadsheet. So maybe this file is not a final version. I've designed single files for every mod, and multiple sheets for every text file in a mod. But yes, ideally you only need to add a column headed by de_DE for it to work, and every line you translate will show in the german version.

To my knowledge, there are translations to russian and polish, but they are translated the same way you did before and somehow got lost. I don't want that to happen again. I consider myself quite lazy and I'd hate to do useless work.

Please, take a look at it, tell me if you see something that can be improved and help me convincing the modders to arrange their text files in a way that's more translator friendly.

EDIT:
This is the file for CBP, without sql files, and removing the definition part of xmls.
https://docs.google.com/spreadsheets/d/1rsfZZzm5t0vR4EUzJipvc-PluD78DSyJ_GUHgfPAlrA/edit?usp=sharing
Notice that there are several sheets, one for every text file in CBP.

I think this is the best solution presented thus far. Existing polish and russian translations should ideally be ported to this, so that I can more easily incorporate them into the CP/CBP.

Thanks, everyone!

G
 
some modifications i made in the PolicyText.sql:
- correct some problem with commentaries
- add French translation

note: this file seems to contains a text that is extracted from a version before G made modifications to autority/progress
How & who is going to update it?

IMO, i prefer to work on a git than on gdoc, easier to see, track & make modifications.

edit: also added PromotionText.sql
 
some modifications i made in the PolicyText.sql:
- correct some problem with commentaries
- add French translation

note: this file seems to contains a text that is extracted from a version before G made modifications to autority/progress
How & who is going to update it?

IMO, i prefer to work on a git than on gdoc, easier to see, track & make modifications.

edit: also added PromotionText.sql

Well, I used latest CPP stable release.
Can't you resize colums for better viewing? You also can adjust text to fit in cells.

EDIT: I shoud have written the version number.
EDIT2: On how and who's gonna update the file, I hope that it will be done by modders, once they release next stable version. Along with the announcement of a new stable version, we may have the new file to work with.
 
Back
Top Bottom