I18N (name pending)

[bartbes]

So I figured I might write an i18n lib, now there are a few questions for you guys:

• Are you guys interested in it?
• Would using existing gettext format be better than lua?

[nevon]

So I figured I might write an i18n lib, now there are a few questions for you guys:

• Are you guys interested in it?
• Would using existing gettext format be better than lua?

• Yes
• Yes

[vrld]

Yes, please do that. And also what nevon said.

To the confused ones: i18n is localization support. gettext is the GNU way to do it.

[giniu]

Also 2*Yes!

Using gettext have a huge advantage of ability to reuse existing gui tools that works really well. It opens new possibilities - a good translation requires native, and from my experience it is easier to find player/user interested in helping by translating thing in some kind of gui, than player/user interested in hacking custom files.

[kikito]

I would be interested on this!

I don't like the PO format very much, if that's what you mean by "gettext format" then I'd rather have a .lua file

A nice to have thing would be the possibility of organizing messages into hierarchies, although it is not a must-have for me.

Code: Select all

i18n.en = {
  main_menu = {
    msg1 = "All your base",
    welcome = "Hello {name}"
  }
}

The thing would probably need parameter interpolation - like the {name} part above. You might end up with something similar to robin's idea for Rich Text format.

Also, pluralization support might be very nice (see section 4.2 and 4.3 here for details about interpolation and pluralization in rails' i18n)

Would you use an external function, or would you just extend strings?

Code: Select all

i18n.t("main_menu.welcome", {name = 'Peter'}) 

vs

Code: Select all

"main_menu.welcome".t{name = 'Peter'} 

Or maybe both at the same time?

[nevon]

I would be interested on this!

I don't like the PO format very much, if that's what you mean by "gettext format" then I'd rather have a .lua file

I agree that gettext is pretty horrible in every way, but there are loads of tools out there to facilitate translations that use this system. For example, if you were to host your code on Launchpad, it's super-easy for translators to do their thing.

[kikito]

I don't think the (arguably) theoretical benefit of having more tools outweights the downsides of having to implement a parser. The i18n lib will be out faster and will be smaller if the .po format isn't used.

[Robin]

Interesting. I'm not sure on the topic of gettext vs Lua. I implemented a simple way of doing l18n for Tribe -- I don't have it here right know, unfortunately, so I can't tell you how I did it exactly. But it was definitely simple both to implement and translate.

[giniu]

Translation is easy if you don't deal with translator that does know his way around in text files. I work (well, sort of - last time some time ago) on project in Erlang which is translated into multiple (11) languages, with approx 120kb of text to translate in each - we use as it seemed to us simple format based on lists and tuples, but there are lots of non-tech people that wants to help us translate it into their language and sometimes try to do it but generate lots of work, troubles with encodings, line endings, etc - they get discouraged quickly. We are actually plan to move to gettext so people can use poedit - you know - like on this screenshot - and have editor deal with it - we probably would have already like 20, not 11 languages if we used gettext from start.

So yes, custom format is easy to implement and write for someone who implemented it or knows his ways around, but really - it's hard for general public, and that's from where translators usually come from. That's why I'd vote for gettext, even at price of a bit longer implementation - especially because such translations usually aren't made by core team, or only few are made and later community adds more - I haven't seen team which could create good, native-quality translations for 20 languages. Just my 2c though.

[kikito]

Ok - how about this:

Get both.

A lua-based config file should be pretty trivial to implement, compared to a .po parser.

I'd recommend implementing the Lua-based solution first and the .po version one year later.