Page 26 of 32

Re: GZDoom localization development thread [Split]

PostPosted: Tue Apr 09, 2019 12:10 pm
by Negostrike
I just finished the entirety of the Brazilian Portuguese translation of the GZDoom engine strings, plus the game strings for Doom and Heretic. Later on will keep working on the remaining stuff. I'm open to feedback.

Re: GZDoom localization development thread [Split]

PostPosted: Wed Apr 10, 2019 8:16 pm
by theleo_ua
Graf Zahl

Tried GZDoom 4.0.0 x64 with this viewtopic.php?f=3&t=13361&start=15#p880966 Hexen Gibbet Glitch fix, and gibbet text (you hear a door open upstairs) is in English (because ACS text of this fix in English)

Is it possible to integrate this fix to GZDoom via gameplay or compatibility options, so this way gibbet text will be translated to selected language? For example to add compiled acs of the fix to zd_extra.pk3, and load it in case of respective gameplay/compatibility setting is true

For any case, I attaching my version of fix, but it's better to use your own version of it

P.S. Also, is it possible to use string values in this acs fix without vanilla gameplay distortion? This way this script will use those string directly from language.xxx and no any gameplay options will be required (but I don't know, does vanilla ACS allow this)

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 2:49 am
by Graf Zahl
If you want to directly reference the string table, instead of using s:"blah", use l:"blah's_label". If you do it that way even a drop-in replacement of the script will pick up the translated string.
To add this fix to the engine I'd have to do a hack in the lump manager to swap out the broken script lump from this map, this is doable but not trivial.

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 3:56 am
by Graf Zahl
I had some time this morning to create a support table for the current set of fonts. You can find it here:

https://docs.google.com/spreadsheets/d/ ... edit#gid=0

To summarize, for the current languages on the support list, it's almost complete except for Chex's BigFont.
However, it looks like there's one character missing from Doom's SmallFont - and since it's a copy - also from Chex's Smallfont, that is the Ò.

In addition, for the languages that are currently being worked on (i.e. Polish, Czech and Romanian) there's 19 characters currently unsupported (one of these has partial support.) These are the ones marked orange in the sheet. So if someone wants to work on extending the font, these should have priority.

One other thing: The Raven BigFonts are missing their exclamation mark (and the inverted Spanish variant as well) I think these should also be added to have all relevant characters in there.

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 4:54 am
by Kinsie
Graf Zahl wrote:One other thing: The Raven BigFonts are missing their exclamation mark

ImageImage

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 5:16 am
by Graf Zahl
Thanks. Could you (or someone else who is interested) make a PR of this, with the normal ones at code point U-0021 and the inverted one at code point U-00A1? They'd also need to be in Doom patch format to be consistent with the rest.
I'd have to wait until late this evening to add them myself.

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 5:34 am
by Rachael
I've gone ahead and pushed it as a commit. I used Kinsie's exclamation points, but by the time he posted them I had already done inverted ones, so I just used those, too.

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 5:43 am
by Graf Zahl
Ok, so 4 down, lots to go... :twisted:

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 5:53 am
by Gez
Graf Zahl wrote:I had some time this morning to create a support table for the current set of fonts. You can find it here:

https://docs.google.com/spreadsheets/d/ ... edit#gid=0

What is the meaning of the various colors? If it were just red and green it'd be simple to guess "green: character present" and "red: character missing" but there's also orange, cyan, teal, white...

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 5:55 am
by Graf Zahl
Look at the second tab which is (gasp) called "Color codes"!

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 5:59 am
by Rachael
Graf Zahl wrote:Look at the second tab which is (gasp) called "Color codes"!

To be fair the presence of those tabs is not obvious to someone who has rarely ever used Google Docs before. >_>

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 6:17 am
by Graf Zahl
It's in the same place as for offline spreadsheets, and the text documents also have multiple tabs.

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 7:24 am
by Undead
Is it possible to make diacritics render above/below letters at runtime? I know Hexen 64 does something like this for the French version.

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 9:01 am
by theleo_ua
Graf Zahl wrote:If you want to directly reference the string table, instead of using s:"blah", use l:"blah's_label". If you do it that way even a drop-in replacement of the script will pick up the translated string.
To add this fix to the engine I'd have to do a hack in the lump manager to swap out the broken script lump from this map, this is doable but not trivial.


Ok, I will try l:"blah's_label" method and will tell you, if it works or not. If it will work, then it's enough, and non-trivial replacement in the engine doesn't needed

Big thanks for the help

Re: GZDoom localization development thread [Split]

PostPosted: Thu Apr 11, 2019 9:32 am
by Graf Zahl
Undead wrote:Is it possible to make diacritics render above/below letters at runtime? I know Hexen 64 does something like this for the French version.


If you do it right, yes. But with graphical fonts the accents often need to be adjusted for the letters. Unicode has a feature for that but the mere fact that every important character also exists in precomposed form tells a lot.