Translating GZDoom's text content. Read if you want to help

[Firebrand]

I'm taking a look at the Spanish translation and I'm already seeing a couple problems, but it's probably because it's actually Latin American Spanish and it's throwing me off. Still, I could probably adjust some things (or also provide a castillian spanish translation).

Well, I'm not the one to do the castillian spanish translation, not an expert on that one .

I know Castillian Spanish uses a bit more "literal" meaning for most stuff, so maybe that's what threw you off with the ones I did?

But I wouldn't have a problem working with someone who wants to make the castillian spanish one and another column for the latin spanish one, the more complete stuff gets, the better for the community .

The original translation was supposed to be neutral, but I cannot say what Firebrand did there. If you want to proofread, I think it's best to take a version from before his first edit and compare.

I changed the Spanish translation strings that didn't sound completely right to me, I also fixed orthography errors and some strings that lacked Capital letters, my idea was to leave most strings as their original English counterparts, if a word has a Capital letter in English, keep it on the Spanish translation.

The rule here should be that the Spanish master table should be Castilian and the Latin American variants be handled like the British English where only the differences get a separate entry.

As I said I wouldn't have a problem with that, what I would suggest is to add a new column for Latin Spanish and copy every string there, once the person working on Castillian Spanish is done with their edits, I could compare both columns and remove the "duplicate" strings, to leave only different ones in that column .

My only question would be, which language code would the new column have to use? "esn"?

[Kostov]

My only question would be, which language code would the new column have to use? "esn"?

Here’s a full list.

[Firebrand]

My only question would be, which language code would the new column have to use? "esn"?

Here’s a full list.

Woah, there is just a lot of Spanish variants, lol .

[Graf Zahl]

For now this isn't relevant. Later, when this gets distributed I'll add the language IDs to the header. Just look at 'language.eng'. But this is a one-time work. Just use esn for now, the important thing is that it can be tested.

Also, since they seem to be the biggest formatting issue, for the intermission texts, they should be tested on a 640x480 or 1280x960 screen. These two sizes provide the minimally available screen space. To make this easier I added a 'testfinale' CCMD which gets both a text and a language ID (in this case the ID must match the header in the language file, this won't be substituted.)

(Technically, 320x200 and 640x400 offer even less space but let's just pretend these do not exist. People using these have to suffer the consequences... )

[Firebrand]

OK, I've added a new column with "esn" language code, I left all strings duplicate, as I said, when someone who wishes to work on Castillian Spanish finishes their edits, we'll compare them all and remove the duplicated ones, leaving only different ones for "esn" language definitions.

When writing both Heretic and Hexen intermission texts, I tested them on 320x240 resolutions (yeah, everything looked blurred on screen XD) and used that one as a way to leave the line endings. Fitting stuff for 320x200 seems a bit too extreme, the options menus suffer A LOT with that resolution, heh!

[Graf Zahl]

I don't think you need to go through the file manually to weed out the duplicates. It's more than 3000 lines!
This is a job for a computer tool that can run on the final output once it is complete.

I already have both an xlsx exporter and an importer working, all this needs is to run the importer, eliminate the duplicates and write it back out again.

[GelleSzebasztian]

Hello! I would also help in translating to Hungarian.

[Graf Zahl]

I just granted you access.

[Rachael]

Going forward, what is the policy for adding language strings?

In the Vulkan branch I created a backend switcher CVAR but I didn't put it on the menu because I didn't want to fuss around with the localization strings that would be necessary for it. As the branch matures I am pretty sure it is not the only string that will require localization in the long run. That also includes additional features outside of Vulkan, as well.

[Graf Zahl]

First I need to clean up and reorganize the spreadsheets. After that new content can be added to them and they will be put into the repo on a regular basis.

[Graf Zahl]

I updated the first post with new links. The old spreadsheet was retired because it mixes things that need to be separate.

[Kostov]

Wouldn’t it be possible to have both spreadsheets in one, but in two different tabs at the bottom?

[Graf Zahl]

No. That wouldn't help me because I need them as separate files.
I tried editing them with LibreOffice but that cannot efficiently write XLSX files (they get blown up to 10x the original size) so I am not able to edit them for distribution locally. I do not have an Excel license so I am stuck doing it this way.

[printz]

Hi, I'd like to contribute with a new language (Romanian). Should I request access to the Google sheets or should I submit a textfile for you to update?

Regarding diacritics ă, ș and ț: if they're missing, you can fall back to their ASCII counterparts. We Romanians are terribly lazy at using them even now when UTF-8 is available. But it would still be appreciated to have them, because words and verb tenses can change meaning depending on their use.

We have the same gender problem as Spanish. Even worse, as some words change their stem a bit when going feminine. Also, when counting things, we put an extra word (de) after the number if it's ending with 20-99. Usual commercial apps just use parentheses or slashes to cover all cases without complicating their localization, but it can look kludgy.

Regarding Chinese: I'd find it more practical to let modders use graphics instead of strings. Downscaling all those complex characters seems nightmarish.

Regarding Japanese: maybe you can get away with kana and spaces (many Super Famicom translations were just using kana), but I'm not sure what Japanese speakers would think of it.

[Kostov]

Regarding diacritics ă, ș and ț: if they're missing, you can fall back to their ASCII counterparts. We Romanians are terribly lazy at using them even now when UTF-8 is available. But it would still be appreciated to have them, because words and verb tenses can change meaning depending on their use.

Unfortunately, I don’t think your translation will make it to the next release, which is in a few hours from now. However, I could make those letters for you as soon as your translation nears completion.

Regarding Chinese: I'd find it more practical to let modders use graphics instead of strings. Downscaling all those complex characters seems nightmarish.

Regarding Japanese: maybe you can get away with kana and spaces (many Super Famicom translations were just using kana), but I'm not sure what Japanese speakers would think of it.

A Japanese translation is already being worked on, and I believe there’ll be a way to get around the font sizes. They can be increased in GZDoom (the only place where this doesn’t work is in Strife’s quest log).