[Mediawiki-i18n] [Potlatch-dev] Internationalization
Ævar Arnfjörð Bjarmason
avarab at gmail.com
Tue Aug 31 10:48:38 UTC 2010
On Tue, Aug 31, 2010 at 09:29, Richard Fairhurst <richard at systemed.net> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Sun, Aug 29, 2010 at 16:54, Nop<ekkehart at gmx.de> wrote:
>>> And on a more general note: Is there a concept for the
>>> 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:
> 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
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
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.
More information about the Mediawiki-i18n