String patch

[ChrisCF]

http://sourceforge.net/tracker/index.ph ... tid=636367

Fixes a few strings in english.txt, regenerated against 514. I'd appreciate it if someone could look at it before the next release. I don't want to have to keep regenerating the patch against new revisions all the time.

[Vurlix]

Then don't. We'll sort it out

[Vurlix]

I implemented some of the modifications. I don't agree with most of the changes, so I left most of it out. For instance, Railroad is more appropriate than Railway. Cotton Candy is a word in my dictionary, but Candy Floss is not. Some changes I modified. Other changes are just plain silly and don't really improve anything so I left those out too.

[ChrisCF]

Your dictionary is broken. (The space between the words is optional)

1. "English" without clarification should refer to English, i.e. English English, not American English or Canadian English, Australian English, Irish English, etc. in the same way that "French" is assumed to be as spoken in France, "Spanish" as in Spain and "German" as in Germany. Of course, there's nothing wrong with having separate translations for these in english_us.lng, english_ca.lng, etc. (though they should really be named per ISO codes, e.g. en_US.lng, en_GB.lng, etc., as this is a standard format which can be read from $LANG on many systems). In English English, the sweet stuff is "candyfloss" or "candy floss", not "cotton candy", and our trains run on "railway" track.

2. Because the currencies are visible to the user, they should be localised, using a symbol familiar to the average person on the street, e.g. someone in India will probably know "Rs." but have no clue what "INR" is supposed to be. Similarly, in many countries with dollars, it is more typical to see the $ sign, occasionally with a prefix (e.g. HK$, T$), than to see things such as HKD, TWD, etc. Ideally, these symbols should be hard-coded, or rendered unchangeable, since the names will be translated to each language, but the symbol should stay the same.

Finally, Latin-1 is *not* a good choice for encoding, and I don't really believe that anything in the game ties you down to it. One of the languages I'd planned to do I cannot, since I'm missing no less than 5 necessary characters from the orthography, and doubtless many Eastern Europeans find themselves without even more. In short, the whole i18n/l10n could do with some overhaul - and it would be considerably less effort to change it now than to change it later.

[Vurlix]

Finally, Latin-1 is *not* a good choice for encoding, and I don't really believe that anything in the game ties you down to it.

Only the fact that the ttd graphics character set is limited to those characters. Moreover, some character codes are reserved for use by the game, such as the {X} control codes. Adding support for the euro character alone involved swapping around character ranges.

The fact is that we can't support every language with any one single character set. The obvious solution is to use multibyte/UTF8, but this would require massive restructuring of the code. Perhaps some day this may happen.

However, another solution comes to mind: character sets could be specified in the language file, such that you can have language files of different character sets. That could work. We'll look into it...

[ChrisCF]

The fact is that we can't support every language with any one single character set. The obvious solution is to use multibyte/UTF8, but this would require massive restructuring of the code. Perhaps some day this may happen.

Would it be a massive change from "draw these sprites" to "use this font"?

I still think that it would be less work to change this soon than to try to change it months down the line, by which point it becomes not so much restructuring the code as rewriting the entire game. As a further hint, if you do change the i18n/l10n mechanism, gettext is your friend There are very good reasons why it's become the most-used method for dealing with multiple languages.

As for the dialect issue, permission to fork some different Englishes? Concept attachments provided.

[Vurlix]

Would it be a massive change from "draw these sprites" to "use this font"

That's essentially what my idea of selectable character set, worded differently. Know that TTD does *not* use "fonts" per say; the characters are simply bitmaps like every other image in the game. We'll have to define some character maps and add the missing characters as needed.

I still think that it would be less work to change this soon than to try to change it months down the line, by which point it becomes not so much restructuring the code as rewriting the entire game.

Eh, the game is already pretty much stable in that regard, so doing it now or doing it later would make absolutely no difference.

As a further hint, if you do change the i18n/l10n mechanism, gettext is your friend There are very good reasons why it's become the most-used method for dealing with multiple languages.

We've gone over this already. We're quite happy with the existing language mechanism, and gettext is a huge library with documentation of monstrous proportions. I fear that we'd be spending way too much time learning to tame it than actually using it. Gettext is *not* our friend. Also, we decided not to add any more dependancies unless absolutely needed.

As for the dialect issue, permission to fork some different Englishes?

For what little good that would do... have fun.

[ChrisCF]

That's essentially what my idea of selectable character set, worded differently.

No it isn't. Using real fonts rather than a set of sprites means you can use whatever character sets your font happens to support => possible UTF-8 support. Of course, if you'd rather people put up with having to draw their own characters because none of the available character sets for the game contain some they need ...

We've gone over this already. We're quite happy with the existing language mechanism, and gettext is a huge library with documentation of monstrous proportions.

Clearly you haven't read it, have you?
There's nothing wrong with the documentation, other than it containing too much about emacs (possibly more, in fact, than the actual library itself). You're just FUD'ing now. It's easier to code with it, and it's easier to translate with it (count on considerable personal experience there). That way, your code says what you mean, not what you believe to be a vague idea of what you possibly think you might mean. Gettext clearly *is* a friend, and is *not* difficult to use. If it were, it wouldn't be the most popular library for l10n there is.

[Vurlix]

We can't use real font files for various reasons:
1) We would need to specify which font to use on every platform or we would have to include an existing, freeware, unicode font (which i don't think exists)
2) It would add yet another dependancy on freetype to render the fonts, which we already decided we wouldn't do unless absolutely necessary.
3) It would be (a little) slower than the current method

Despite all that, looking far, far into the future, we might end up using freetype and support just about every characters found in unicode, but I wouldn't count on it.

We can't use gettext either, because THAT would require a complete rewrite of the string handling, which is NOT going to happen. Sorry, but gettext is out of the question. Unless, of course, you're willing to spend a year converting the string subsystem.

[ChrisCF]

We can't use real font files for various reasons:
1) We would need to specify which font to use on every platform or we would have to include an existing, freeware, unicode font (which i don't think exists)

There are rather more such fonts than you think. Finding them is left as an exercise for the reader.

We can't use gettext either, because THAT would require a complete rewrite of the string handling,

Example:

Code: Select all

	if (engine < NUM_NORMAL_RAIL_ENGINES + NUM_MONORAIL_ENGINES)
		return STR_8106_MONORAIL_LOCOMOTIVE;

Code: Select all

	if (engine < NUM_NORMAL_RAIL_ENGINES + NUM_MONORAIL_ENGINES)
		return gettext("monorail locomotive");

Major rewrite ...
As for formatting currencies, numbers, dates, etc., the locale data in the standard library means you don't have to format all that, since there are things that will do that for you. The only thing that might pose a small problem is colour codes, but that can probably be worked around very simply.

I'm not trying to be funny, but you're just being stupid now

[Vurlix]

Right. We're all waiting for you to make gettext work with openttd then.

[ChrisCF]

Simple steps:

1. add #include <libintl.h>
2. add #define _(a) gettext(a)
3. replace all incidences of STR_whatever with _(STR_...)
Alternatively, if you can write the appropriate scripts, replace them with _("Actual string referred to") - though I'm not writing such a script for you
4. "xgettext -n -D . -d openttd -p $dirname -w 76" where $dirname is where the string files will be (typically one of 'po' 'nls' or 'lang')

... and you're finished. You can run the results through whatever currently does character replacements, since the strings can still contain the {BLACK}-style macros (with instructions telling people not to change them).

[ludde]

i like it when people talk without having a clue.

[spaceman-spiff]

i like it when people talk without having a clue.

Why don't you un-clue it then

[ChrisCF]

i like it when people talk without having a clue.

Exactly what part of the string replacement mechanism did I miss? As far as performance goes, the hit is fairly minimal. When at the top of a tall building, it might be quicker to just jump off the roof, but I'd take the lifts if you don't mind