Messages

1

Translations / Re: New text strings

« on: April 08, 2013, 02:40:18 pm »

They're two strings used in different places, not a pluralization.

Yes, but we should still use the translation's support, because different languages have more than one plural form, depending on the actual number referenced.

2

Translations / Re: New text strings

« on: April 07, 2013, 06:18:47 am »

STR_LIVING_QUARTERS_PLURAL
used in the base information screen to describe how many of that facility type you have operational.

This should use the translation's ability to provide different forms (like the STR_DAY_* strings), so we can use the proper forms from different languages.
I'll look into it.

3

Programming / Re: Question on alien appearance ratios

« on: March 10, 2013, 04:24:40 am »

Looking at the Xcom1Ruleset.rul, I see that I have missing races for the Alien Abduction type missions. However the rest of the missions types are correct. Are you sure you have the proper ruleset file?

4

Translations / Re: Translator feedback required

« on: February 22, 2013, 09:24:00 pm »

Ok, the code is fixed and the PR is send. Thank you for spotting this.
The error was in the actual translation code, not in the language files.

5

Translations / Re: Translator feedback required

« on: February 11, 2013, 08:21:07 pm »

The string matching is verbatim, so can you re-type the ID strings in the language file, AFTER deleting the lines that contain them?
Like so:
1. Delete the line that reads "STR_n_UNITS_IN_EXIT_AREA_0".
2. Retype the STR_n_UNITS_IN_EXIT_AREA_0 in a new line at the proper place.
3 and 4. Do 1 and 2 for STR_n_UNITS_IN_EXIT_AREA_1.

If this works then some special characters got in the language file when I edited it. I don't really think it probable, but the code looks ok.

6

Translations / Re: Translator feedback required

« on: February 11, 2013, 08:03:46 pm »

Are you SURE the language file with the variant strings is in the proper place?
Do you see any line mentioning STR_n_UNITS_IN_EXIT_AREA in the logs?
Can you also add a STR_n_UNITS_IN_EXIT_AREA_2 with a dummy value (eg "This should not appear EVER!") and check if you get that value?

I'm pretty much drowning at work right now, I won't be able to take a look before the weekend.

7

Programming / Re: Paletted 8bit -> 24bit shading.

« on: February 02, 2013, 06:58:35 am »

The number of tiles we count is NOT the number of grid positions in the battlescape. It is the different contents that can appear. e.g. All alien UFO floors are the same tile. Right now this is hardcoded at 256 (one byte index), same as in the original game.

8

Translations / Re: New text strings

« on: January 30, 2013, 01:58:22 pm »

I have made some changes that enable translating complete some complete sentenses. Also changed some code to use count-depended code.
I have placed the strings last in the file, based on original language content (see commit 7433e2).

The following now have a '{1}' marker where the actual craft name will appear:
STR_EQUIPMENT_FOR => STR_EQUIPMENT_FOR_craftname
STR_SELECT_SQUAD_FOR =>STR_SELECT_SQUAD_FOR_craftname

The following have many forms, based on the value of n: The suffix "_0" means the form will only be called if n is 0, the rest are language specific. All can handle a '{N}' marker that will be replaced with the actual value.
STR_n_UNITS_IN_EXIT_AREA
STR_n_UNITS_OUTSIDE_EXIT_AREA

There is also a STR_ABANDON_GAME_QUESTION, which only the Spanish translation should care about (because it needed to have the extra inverted '?' at the front).

9

Programming / Re: Paletted 8bit -> 24bit shading.

« on: January 28, 2013, 04:44:48 pm »

why 256 nw and 256 ne? there's only ONE tile set per map. and there's a limit of 256 tiles per map. though it may have animated tiles (but there are only few of them), which _slightly_ increase overall sprites count.
but the thing is - units also need to be "shaded" properly, though they could be flat shaded.

and still, that would work only for 8bit original graphics. still no way of such "oldschool" shading for 32bit "HD" sprites from TTS.

Don't we keep the images for NW/NE/floor and central object as separate sprites? If we don't, then it's true that we only have 256 sprites max (for terrain). Although I think the 256 tile limit can be lifted easily enough and become 2^16 (a few typedef changes and a small change when reading from the original data).

10

Programming / Re: Paletted 8bit -> 24bit shading.

« on: January 28, 2013, 01:14:19 pm »

Having every shaded version in memory at the same time is very expensive because we may have (by definition) 256 different tiles. And 256 different NW and 256 different NE and 256 different center objects. Which adds fast to huge amounts of memory.

Going to 32 bits of colour (RGBA), with premultiplied Alpha, allows us to do tinting and lighting as a simple shader (I think) or alpha blending (I know). We may lose some of the original colours, but we are talking about a visual overhaul anyway. And we get room / possibilities of many more effects, like properly transparent smoke,  translucent flames, grayscale-as-fog-of-war and depth bluring at almost no extra cost.

11

Programming / Re: Paletted 8bit -> 24bit shading.

« on: January 22, 2013, 09:08:45 pm »

The problem, as I understand it is the following:
The paletted image files contain the palette index for only one shade of the colour (colour group).
Right now we shade by moving inside this colour group, which contains the various shades.

Since we have the actual values of each shade for each group, we could plot the curve of shade, component and see if we can find Gamma that gives an approximate curve when used as pow(shade, component Gamma).

Shade and component are normalized to [0,1] (shade was [0,15] and component [0,255]).
I'm guessing that there should be a set of gamma functions that corresponds to these shades or that can approximate them good enough.

EDIT: You mean there are indices that are the same offset in different groups and have the same RGB value? And they are the original colour in the image (the data saved on file)? eg FAKE EXAMPLE to make it clear: Offset 0 in first group (warm wood) and 0 in third group (dark concrete) have the same RGB values and the image data contains a 0 in both cases? Because if that it the case then we have indeed lost information. But if it's not, then we may be able to get a good enough approximation.

12

Translations / Re: Translator feedback required

« on: January 20, 2013, 01:03:23 pm »

This is exactly why this thread exists. In the code I use the rules for each language to look up special strings when a number is involved.

I have a way to specify the rules in code (and the rules for Russian are already there), exactly as you mention them.

If the special treatment is asked for a key based on a number n (eg STR_SOLDIERS_IN_CRAFT), the following are tried:
If n is 0 the STR_SOLDIERS_IN_CRAFT_0 is selected, if it exists. This happens for all languages.
Based on each language different rules are used, and one of keys STR_SOLDIERS_IN_CRAFT_1 to _K are selected, based on the language. _1, _2 and the rest may have different meaning for each language, they are NOT the number n. It is simply the k-form in the rules for the specific language. So, while English and French both use _1 and _2, for English _1 is used only for singular and _2 is used for plural and for zero (if _0 is not found). For French _1 is used for singular and as the zero fallback, while _2 is used for plural.

Please check the rules in the source code (file src/Engine/Language.cpp) it should be easy enough to understand the various "getSuffix" functions for the different languages.

The problem is that a lot of the strings are created from smaller pieces (eg words) and thus the actual game code needs to change to use the new translation facility and make sentenses that the translators can modify. As a fictional example:
Now the code is like:

Code: [Select]

message = translate("STR_THERE_ARE") + n + translate(n == 1 ? "STR_SOLDIER" : "STR_SOLDIERS") + translate("STR_IN_THE_CRAFT")
and the translators only see the "STR_" strings.

It should be changed to

Code: [Select]

message = translate("STR_THERE_ARE_N_SOLDIERS_IN_CRAFT", n)

and then the translator for (Rusian?) will see:
STR_THERE_ARE_N_SOLDIERS_IN_CRAFT_0
Some rusian for żołnierzy or sztuk
STR_THERE_ARE_N_SOLDIERS_IN_CRAFT_1
maybe {N} sztuka or {N} żołnierz
STR_THERE_ARE_N_SOLDIERS_IN_CRAFT_2
maybe some {N} sztuki or {N} żołnierzy
STR_THERE_ARE_N_SOLDIERS_IN_CRAFT_3
maybe some {N} sztuk or {N} żołnierzy

while the translators for French will see:
STR_THERE_ARE_N_SOLDIERS_IN_CRAFT_0
French for no soldiers in craft
STR_THERE_ARE_N_SOLDIERS_IN_CRAFT_1
French for a single soldier in craft
STR_THERE_ARE_N_SOLDIERS_IN_CRAFT_2
French for {N} soldiers in craft

And the English text will be:
STR_THERE_ARE_N_SOLDIERS_IN_CRAFT_0
No soldiers in craft
STR_THERE_ARE_N_SOLDIERS_IN_CRAFT_1
A single soldier in craft
STR_THERE_ARE_N_SOLDIERS_IN_CRAFT_2
{N} soldiers in craft

And if the _0 form is missing in English, the _2 form will be tried, but for French the _1 form will be tried.

13

Open Feedback / Re: Next version number (0.5)

« on: December 08, 2012, 11:34:42 am »

i vote for 0.5, because 0.9 is too optimistic. it's never late to jump on 1.0, but it will be problem to enlarge 0.9->1.0 distance.

My thought exactly!

14

Programming / Re: Refactoring translation

« on: December 04, 2012, 11:50:28 pm »

- Why did you encapsulate strings inside a LocalizedText?

Because this allows me to add the 'arg()' function and allow call chaining for argument substitution. It also makes it clear what is translated and what isn't. To take full advantage of this we should make all user-visible functions accept LocalizedText arguments so that translator-unfriendly code would trigger compilation errors. But that's a very big change for a small gain in the way the game is written right now.
The proposed code has no overhead and allows readable translation code, without changing too much. It just stops string concatenation with '+', requiring wstringstream instead. Which is good, since this indicates that proper translation-aware code should be substituted there (using LocalizedText::arg for most cases).

- What's OX_REQUIRED_RESULT?

It is hides compiler specific code to warn about unused results of "expensive" functions, eg code like

Code: [Select]

_game->getLanguage()->getString("STR_ID").arg("Example"); https://Nothing is done with this.

VS

setText(_game->getLanguage()->getString("STR_ID").arg("Example")); https:// This is ok, we are using the result.


- Why should the program crash on a blank string?

Ok, crashing is kind of overkill, but that assert only triggered when someone wanted a translation for the empty ID, so it is a logical error in the code, or in the rule set.

- Should PluralityRules really be a programmer concern instead of a translator concern? It's gonna have to be maintained everytime a new language comes in, all this for one plural word.

PluralityRules is used for the generic code to support all different types of plural forms (not just 2 as in English).
It allows the programmers to call a single function and have the translators provide the proper forms.
And the implementation is such that for most languages only a single line needs to be added (if they are the same as another supported language). Only a language that has different rules needs more code, and even then it's a simple enough class that can be written by anyone, if he/she understands the language in question (or has the rules provided by someone who does).

PS: I agree that the current game code does not allow the new translation code to show it's true potential, and it may seem overkill. But I think that using it will allow better translations as the rest of the game eventually gets re-written to take advantage of it. If we don't have the translation code, these possibilities will never be taken, and the translations will always be sub-par, no matter how hard the translators try.

15

Programming / Re: Refactoring translation

« on: December 03, 2012, 12:50:35 pm »

I have now added a new PR, containing just the minimum code changes, without changing all the states to use the 'tr()' functions.