Common game translations

[bartbes]

Because string.gsub is awesome, how about..

Code: Select all

function CommonLocal:get(section, key, ...)
    local line = self.strings[section][key] or ''
    if line == '' then
        return 'Translation Not Found'
    end
    local arg = {...}
    return line:gsub("$(%d+)", function(i) return arg[tonumber(i)] end)
end  

Though perhaps it makes sense for the replacements to be translated too?

[BozoDel]

It's currently generating .ini files, and I'll probably be looking into some other formats if they would be useful. If you guys have any other formats you think would be useful, please let me know!

I would suggest, for small and medium-sized strings, a tab-delimited glossary (simple utf8 encoded text, first column is source, second is target, third is comments, that's what OmegaT reads). For strings of any size, a TMX translation memory would be most useful - it's XML though.

[DanielOaks]

Though perhaps it makes sense for the replacements to be translated too?

I've been meaning to, my computer was being a bit dodgy and not letting me add it in the doc, so thanks to whoever put in the lang/error.missing line!

That gsub thing does look like the right way – I'm a mostly-Python programmer so I'm not as familiar with the Lua idioms yet. I'll make sure it runs fine and push it to the repo. Thanks for the suggestion!

TMX looks like it should be doable. Honestly, I don't like XML, but when I can get to it, it shouldn't be too bad hopefully. edit: That is, generating a TMX file as output. The tool still works purely off the XLST of the Google Doc for input, and that'd take quite a bit to change up.

As far as a glossary, I'd like to make up a HTML glossary of strings, a simple static page on Github Pages where you can scroll through and see what's available. I'll look into that a little later though in my downtime.

Bozo, for the tab-delimited glossary, I'm not too sure how it'd be structured or how it'd be used – what source and target mean for instance. Just to be used as a glossary for humans to look through?
Mind giving me an example with a few lines and two sections, please? (a few lines from lang/audio each, something like that so I can see how that would be handled)

edit: That gsub change and localising the "Missing translation" message are now done in the Github repo

second edit: I've also been working on a simple little library called FallbackFonts that lets you load and use several different fonts at the same time. For instance, I'm using it so that I can have the English, CJK, Arabic, Thai, and Hebrew fonts all loaded at the same time, and have the library automatically choose which font to use when I print text. Practically required with all the different languages this thing's supporting

If you're interested or want to see how it works, take a look here in main.txt, and in the fbfonts library: https://github.com/DanielOaks/common-lo ... ve-project

Or you can dig into the Love file here: https://dl.dropboxusercontent.com/u/478 ... Local.love

[BozoDel]

Bozo, for the tab-delimited glossary, I'm not too sure how it'd be structured or how it'd be used – what source and target mean for instance. Just to be used as a glossary for humans to look through?
Mind giving me an example with a few lines and two sections, please? (a few lines from lang/audio each, something like that so I can see how that would be handled)

The source is the original language, the target is the language the game is being translated into. OmegaT is a tool that helps translators in many ways, and one of them is displaying a glossary. For each sentence being translated, it searches for terms or expressions in the source text that match entries in the glossary, and displays only those.

Other translation tools may use glossary formats other than tab-delimited text files, but that's the main format for OmegaT, which is probably the most famous open source translation tool. It's also easy to edit manually, if needed. OT also reads TBX, though, which is an open standard.

The format is simple. Each line is a new term, divided into columns, which are separated by tabs. So it's like:

Code: Select all

source term TAB target term TAB optional comment

but with " TAB " replaced with actual tabs. I'll upload an example.

[DanielOaks]

So with the creation of TBX files, what are we looking to use them for?

Are we looking to make it easier for translators to download a TBX, do a few translations, and then contribute them back into the Google Docs spreadsheet? Or are we looking to produce them so games can use something like a TBX library and use those files instead of ini/some other files to do their translation?

If we're looking to do the whole contribution back thing, that's going to take quite a bit of work. I'm sure it can be done... somehow, and eventually, but it'll take a while to go through it.

[BozoDel]

So with the creation of TBX files, what are we looking to use them for?

Are we looking to make it easier for translators to download a TBX, do a few translations, and then contribute them back into the Google Docs spreadsheet? Or are we looking to produce them so games can use something like a TBX library and use those files instead of ini/some other files to do their translation?

If we're looking to do the whole contribution back thing, that's going to take quite a bit of work. I'm sure it can be done... somehow, and eventually, but it'll take a while to go through it.

From the Okapi wiki: "Because TBX is quite complex, its adoption has been slow". Now that I checked, it seems both OmegaT and Okapi suppor TBX as read-only. I say we ditch it. Not to be confused with TMX, though. TMX can be easily exported and merged etc.

I only had mentioned TBX for the sake of completion, and because it was supposed to be an open standard, but I insist on TMX and tab-delimited text. With those, it shouldn't be hard to contribute back to the project. If you want, I can describe in more detail how they work in OmegaT.

[DanielOaks]

Ah, sure. But how exactly are we looking to use those TMX files – purely as files that client programs can use (as an alternative to the ini/lua libraries), or so that people can actually use their translation software along with the TMX files to contribute translations back to the project?

If it's the second one, I'll need to have a good look into hooking up the system to do that, going through the Google Docs API other fun stuff to try and hook that sort of thing together, just outputting a diff and telling them to change the spreadsheet themselves, if we're looking to do that I'll need to look and see what the best option for that integration is.

[BozoDel]

TMX is not really a way to replace ini/lua libraries. It is meant to help a translator.

See, translation tools extract the text to be translated and split it up into segments. Then the translator translates the segments one by one. At every new segment, the software compares the source text with all entries in the TMX. If it finds text that is the same or very similar to the one being translated, it sends that translation as a suggestion, that the translator can approve as it is or adapt.

After the translation, a new TMX file can be generated, containing all translated segments. It's probably possible to merge them into the spreadsheet. But what is the scope of this project, anyway? If it's just about generic menus and stuff like that, then it's probably not worth the trouble.

And I think it's possible to use Okapi Rainbow to extract a TMX from the spreadsheet. In that case, you wouldn't have worry about that. Imma go check how it can be done.

Edit: Yep, it's not hard to download spreadsheet pages and make a TMX out of them. It is a several step process tho.

[ivan]

Hey, thanks to everyone who has contributed.
This is a neat project and I hope to expand it in the future when I have more time.
If you speak another language, help us out at:
http://goo.gl/fhnw1t

As an update, I have modified the string id's to accommodate different variations based on length, for example:

Code: Select all

display.res=Resolution
display.res\short=Res.
display.res\medium=Display resolution
display.res\long=Application display resolution

Pluralization is handled like so:

Code: Select all

points.one=Point
points.other=Points

Where ".one" is used for one instance and
".other" is used for zero more than one instance.

[BozoDel]

Pluralization is handled like so:

Code: Select all

points.one=Point
points.other=Points

Where ".one" is used for one instance and
".other" is used for zero more than one instance.

Won't work for all languages out there. See Unicode's Language Plural Rules. And I knew about those because of kikito's l18n.