On Tue, Aug 31, 2010 at 09:29, Richard Fairhurst richard@systemed.net wrote:

Ævar Arnfjörð Bjarmason wrote:

...

On Sun, Aug 29, 2010 at 16:54, Nopekkehart@gmx.de  wrote:

...

And on a more general note: Is there a concept for the internationalization of P2?

It could use the system that Potlatch v1 does. It's relatively easy to add support for that.

P2 is a slightly different kettle of fish because Flex is involved. You can't just pull stuff in at runtime (as P1 does) without making the .mxml files unspeakably horrible.

Yeah, I haven't looked at how to do it in PL2...

This is the best alternative I've found:        http://www.gridlinked.info/amazing-i18n-solutions-for-flex-3-4/ which I guess could be wired up to translatewiki somehow.

..but whatever it ends up using should be easy to hook into Translatewiki. It's just a matter of the messages being available somewhere for Translatewiki to pull them from, and for it to update it and submit them back to PL2.

(From my point of view, the one thing I'd like to improve over P1's internationalisation is that the English messages should be in the source, not in en.yml. It makes the UI much more readable and maintainable.)

Yeah, we discussed this on IRC a while back. You'd like something more gettext-like, while Translatewiki is more geared around the "abstract key => translation" model.

But it can do gettext-like too, it does this for Status.Net already. It just does so by deriving a key from the raw message itself.

This means though that when you change the original message you won't get the old message for context in the history, and translators will see it as a brand new message instead of seeing a diff between the old and new.

This is partly just due to lack of support in Translatewiki, but it's also somewhat inherent in the gettext model. GNU gettext sometimes fails to mark messages as fuzzy on upgrades and thinks they're brand new messages if you move the source around a bit.

So while it might be a bit easier for English speaking developers to read gettext-y source it's also useful to keep in mind the extra work that may be created for translators.

And much of the issue for developers can be easily mitigated by choosing more understandable keys in the first place, something that Potlatch 1 *didn't* do, mostly because the YAML has was a flat namespace and I had to work with existing code, so they weren't very internally consistent. The Rails Port is a lot better in this regard.

Anyway, whatever PL2 ends up going for I'd be happy to help with it.