Spring RTS Engine

Com'on, even the Swiss don't use those. And by the way, Cultures are different. We, the nordic people, do absolutely *not* want any lame translation to our own language. We are just happy to use the english and original one, thank you very much.

I wish i could stop google from directing me to google.fi too...

ZK unit translations

http://code.google.com/p/zero-k/wiki/UnitGuide

Ideally someone would want localization support in games hard enough to implement gettext support in lua. That would be a scalable solution leveraging existing tools for translation and every game could benefit from it.

would be nice to see support for font system to cover it but translation and all of that are another matter. The only reason I mentioned the translation bit is because people have to generate that. Engine support is one thing, expecting people to maintain up to date translations of unit descriptions etc.. yeah pipe dream.

Again, I was NOT trying to say that the font system update would be an unrealistic request.

It will not be changed in a short time.I start to translate game introduction,and some introduction are fall behind than current version.Let's go on in a suitable time.

We could at tooltip soundfiles. Speaking Icons? Anyone. Argh.. now im evil Picasso again, suggesting evil stuff. Weres my silly hat... ah there it is.. right in my corner.

Most engine developers who have said something related to this are mostly wrong(Tobi, jK, abma etc..)

It is relative easy problem and I did it few months ago mostly ready.
Lua gettext is just a simple table seek like: return myLanguage[text] or text


ZK way of doing things is just horribly broken in many ways.

Pako wrote:ZK way of doing things is just horribly broken in many ways.

more info please... "its broken" is useless critism.

afaik stuff like IME input isn't supported as well... also right to left languages shouldn't work, too... and no, imo thats not easy to fix.

abma wrote:more info please... "its broken" is useless critism.

-UnitDef customparams is a bad place to save translations(many reasons)
-the UnitDef files seem to have random encodings and mostly wrong
-chars like "äöå" are replaced with 'ae' or other crap when there is no need for that if the file encodings are set correct
-a player can not use his own translations?

Lua supports utf-8 just like other languages do, and even better.

Spring is mostly utf-8 ready but some noobs use these fail text editors which store header for utf-8 like old np++, it is just wrong and the definition files fail to load if that kind of editor is used. Only thing which needs update is font rendering. Engine console and console input never need utf support because it is better done with Lua.

other todo:
-loading a font from multiple files because most font files doesn't have Chinese or other chars
-loading from OS font files?

You just said "its bad mmmmk" ...

No information given.

You said that custom params is wrong for many reasons.. what are the reasons? How do lua only alternatives compare?

You said that encodings are wrong - of course some files are buggy and we have to use silly encoding anyway not utf-8.

And regarding user's own translation .. WTH? You cant be serious here.. how many % people would do that .. oh look I made my own rtanslation of mass effect!

Licho wrote:And regarding user's own translation .. WTH? You cant be serious here.. how many % people would do that .. oh look I made my own rtanslation of mass effect!

My first `hack` was a translation of CivI

So that was a rhetoric question? What kind of people would group up in a comunity to do volunteer work?

Maybee the masochist guild of carpenters and leathermakers? ;D

jK wrote:

Licho wrote:And regarding user's own translation .. WTH? You cant be serious here.. how many % people would do that .. oh look I made my own rtanslation of mass effect!

My first `hack` was a translation of CivI

People did it all for the time for japanese GB roms and continue to do so, going as far as hex editors

or so the tale would go, if the translator didnt miss-understood that part about tentacles going into every orrifice :D

Pako wrote: Lua supports utf-8 just like other languages do, and even better.

This is completely wrong, Lua doesn't support UTF-8, and certainly not better than other languages:

1) You cannot say a language supports UTF-8 or not, it depends on the library.
2) The Lua string library has no support for UTF-8 whatsoever, Lua strings are unencoded blobs of bytes, and that is what all string methods assume.

So for all practical purposes Lua does NOT support UTF-8.

This will lead to surprises such as: Same thing applies to Spring. It also does NOT support UTF-8, it just supports strings of bytes and assumes that 1 character == 1 byte. (In practice many things may appear to work, but at some point you may hit bugs caused by the lack of proper support for UTF-8.)

Some background info: http://www.joelonsoftware.com/articles/Unicode.html

flyweight little pictures for the weeeerk...

Tobi wrote: 1) You cannot say a language supports UTF-8 or not, it depends on the library.

Yes, you can. A language supports UTF-8 if it comes with the compiler. One can also say that a language supports UTF-8 if it's standard library supports it.
Examples of languages that support UTF-8 by default: Python, Java (perhaps many other JVM languages?), C# (perhaps many other .NET languages?), C++1x (http://en.wikipedia.org/wiki/C%2B%2B11# ... g_literals).

Those languages consider UTF characters (if they have that concept) as "wide-bytes", so they are completely different from Lua's 8-bit unencoded "support" I guess.

Good point, if there are specific Unicode literals or a built-in Unicode data type (Python, Java), or you can make variable names containing non-ASCII characters, then you could say the language supports Unicode.

Neither is the case for Lua though. Neither the language nor the standard library support Unicode.

I gather somebody changed the settings for the default type of char in VS and forgot to turn it off, resulting in char being typedeffed to be the same thing as wchar

hoijui wrote:what you want seems to be internationalization support, which is not the same like UTF-8 support. niether is likely gonna happen anything soon (or ever) though, sorry. even if you would volunteer to do it... we could most likely not accept it, cause for this, you need to change 1 out of 10 lines in the source code, which means that all branches are basically unusable after this, if they have a reasonable ammount of changes.
so.. the basic, technical work is not too complicated, but it would cause a lot of workflow problems, and it is very boring work.
that is my view, at least.

UTF-8 alone allows chat in Chinese. They aren't retarded, they are taught the roman alphabet in school, they can read unit names and defer unit behavior through experience, but lack of UTF-8 support means if they are playing together they can't actually chat to eachother in game (or in lobby likewise)

It isn't THAT bad is it? How much spring code is legitimately dependent on the ASCII standard? Just the chat level data transfer code needs to be modified, not the entirety of the coded system. I mean, I'm not gonna do it, but is it really that hopeless?

[edit] after reading through the rest of the thread, I'd encourage the developers here to stop debating full universal text relations or the ability to customize translations for mods, that should be considered a long term goal. If lobby can support UTF-8 for chat and game names, and in-game can support UTF-8 for chat, that would be fully sufficient for every international player to participate with their local brethren. No one in the world right now is not taught the romanic alphabet. They can read unit names, they can distinguish between building a flash and building a raider. The issue is they can't actually talk to each other in a meaningful way. That could be fixed souly by allowing Chinese/Arabic keyboards to actually input their native characters into the systems.

Those systems are remarkably adaptable. The internet, after all, is fundamentally american. Eastern software is specifically designed to Jerry rig into systems with the least possible effort on the part of the western designed software.