a/-clean menu mutlilinguism ( the current interface is still full of english - po files are uncomplete)

Yeah, I think this is absolutely essential. I think it would be fantastic if Dimo could do this -- to be honest it's not something we at TOPP have a lot of experience with, and it's also not likely to become a high priority for us anytime soon. (Though we could really use a Spanish-friendly version of http://openplans.org..) So this would be a great contribution that makes a lot of sense to come from Dimo.

I'll reply in more detail to Dimo's follow up about this over the next day or two -- Dimo, let me know if you think I should CC OpenCore-dev in my reply.

Στις 02-10-2008, ημέρα Πεμ, και ώρα 16:10 +0200, ο/η

> a/-clean menu mutlilinguism ( the current interface is still full of

> english - po files are uncomplete)

Ethan, do you think we could include i18n support as a core feature of

OpenCore? It's very important for OpenFSM/ESF and it doesn't seem

efficient to only include it in their customization layer. I'll need to

override some of your code (e.g. the project_noun function and how it's

memorized) in order to have a 100% translated interface. It may not be

that much work but it would feel a lot better if your future development

is not based on the assumption of an English only UI.

Also, do you have a script that generates the po file? I couldn't find

it anywhere. I can move this thread to opencore-dev if you prefer, but

it would be good to have a bit of feedback from you first, (e.g. about

TOPP's reaction to your Malmoe stories)

 

followup from Paul (slinkp)

Aside from having menu-selected languages, which would be great, we need much more thorough i18n in Opencore: most strings in templates are not marked with i18n:translate, and most strings in Python code are not marked with _(...).  I would really welcome help with this -- it's a pretty easy but tedious task that would go a lot faster with more help.

I would also be thrilled if any of the openfsm.net translations could be shipped with Opencore. Dimo, would that be possible?

I've just updated a page with tips for developers about working with i18n in opencore. If anybody finds anything wrong with that document please let me know; I am not an expert in this area.

Finally, we need to solve our "az problem": we currently abuse the "az" locale for testing purposes, which means any of the 8+ million speakers of azerbaijani might find opencore rather user-unfriendly.  This is obviously a bad idea. Python's gettext module would happily support a fake "test" locale instead; but we would then not be able to test this locale in, say, Firefox by setting the preferred language, because it only supports the commonly known language codes.  Any suggestions for working around that?

 

followup from Dimo

Thanks for your great work Paul. I'll pick it up sometime next week and fix/document, any remaining issues. I'll also commit all available translations.