New era of MusicBrainz' i18n

[Nikolai Prokoschenko]

Greetings!

As most of you probably know, we are starting a new i18n effort for
MusicBrainz. Since this list has been dead for almost three years now,
I'd like to hear some voices from subscribers combined with their
vision of i18n'ized MB -- what you need, what you'd like to be
implemented etc. This is a long-term effort so but this means that
almost everything can be taken into consideration.

So let's get this going!

Nikolai

_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

[Mustaqil Ali]

Some parts of this message have been removed. Learn more about Nabble's security policy.

In my opinion, the following are needed;
 * An actual plan of how to carry out translations - timeframes and release cycles with regards to EN site updates.
 * A list of people who are willing to/are working on i18n - their languages and/or what their role is.
 * Somewhere centralised where translations are stored, be it SVN (in which case patches and updates are sent to a designated i18n-keeper who has write access) or web service.
 * A way in which translations for specific languages to be discussed without polluting an entire mailing list. Extra mailing lists? Forums?
 * Some sort of lexicon tool for saying translate X into Y for consistancy's sake.

This is as much as I can think of off the top of my head before actual translation work should begin. I'm sure others have other ideas and whatnot. :) (All this kind of stuff should so get wikified at some point too...)

--
Muz

---

From: Nikolai Prokoschenko <nikolai@...>
To: musicbrainz-i18n@...
Sent: Wednesday, 11 February, 2009 19:48:17
Subject: [mb-i18n] New era of MusicBrainz' i18n

Greetings!

As most of you probably know, we are starting a new i18n effort for
MusicBrainz. Since this list has been dead for almost three years now,
I'd like to hear some voices from subscribers combined with their
vision of i18n'ized MB -- what you need, what you'd like to be
implemented etc. This is a long-term effort so but this means that
almost everything can be taken into consideration.

So let's get this going!

Nikolai

_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

[Simon Reinhardt]

Mustaqil Ali wrote:
>  * Some sort of lexicon tool for saying translate X into Y for
> consistancy's sake.

I'd be careful with that because things translate differently in different contexts and you might not realise that something is a different context but just happens to be exactly the same phrase in English.

Adding to that:
An easy-to-use interface where you can see all untranslated strings and add translations (and also revise already translated strings and look at translations into other languages for comparison). Jamendo had/has something like that. The problem with it was that you had no context for the strings so you never knew if your translations were correct. Maybe each string should be related to a list of pages on which it is used.

For the i18n itself:
- Make pages / recurring elements or the strings from there translatable.
- Make some of the data in the database translatable (the table of language and country names - although there are datasets out there which do that already).
- Localised number and date formats (remember: this is country-based, not language-based).
- Page layout needs to be rtl'able.
- Page layout has to cope with strings which are much longer / shorter than the ones it was originally designed for.
- Evaluate Accept-Language HTTP headers and do geo-targeting (there should be web-services for that) first to get an initial selection of language + country.
- Somewhere on every page there should be a selection for language and country. This overrides the initial selection. For unregistered visitors, this sets a cookie. For users who are logged in, this could change an account setting.
- The encoding of the pages is UTF-8 already, so no change needed there.
- Set lang and xml:lang attributes on html-tag accordingly. Set it to the release language + script on every element surrounding release and track titles.

All I can think of. :-)

Simon

_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

[Brian Schweitzer]

Just to throw out two other thoughts:

As luks pointed out in IRC, for the Javascript text translations, pulled via a different request manner on the fly, should be kept to a separate set of po's, to minimize the size and load-time for such on-the-fly translations.

Also, for the various languages, would it be worth our starting to get lists together of who speaks what languages and is willing to translate, to try and organize "translation teams", and identify one person from each team to be the one to decide that a particular translation is ready to commit?

Brian

On Wed, Feb 11, 2009 at 5:25 PM, Simon Reinhardt <simon.reinhardt@...> wrote:

Mustaqil Ali wrote:
>  * Some sort of lexicon tool for saying translate X into Y for
> consistancy's sake.

I'd be careful with that because things translate differently in different contexts and you might not realise that something is a different context but just happens to be exactly the same phrase in English.

Adding to that:
An easy-to-use interface where you can see all untranslated strings and add translations (and also revise already translated strings and look at translations into other languages for comparison). Jamendo had/has something like that. The problem with it was that you had no context for the strings so you never knew if your translations were correct. Maybe each string should be related to a list of pages on which it is used.

For the i18n itself:
- Make pages / recurring elements or the strings from there translatable.
- Make some of the data in the database translatable (the table of language and country names - although there are datasets out there which do that already).
- Localised number and date formats (remember: this is country-based, not language-based).
- Page layout needs to be rtl'able.
- Page layout has to cope with strings which are much longer / shorter than the ones it was originally designed for.
- Evaluate Accept-Language HTTP headers and do geo-targeting (there should be web-services for that) first to get an initial selection of language + country.
- Somewhere on every page there should be a selection for language and country. This overrides the initial selection. For unregistered visitors, this sets a cookie. For users who are logged in, this could change an account setting.
- The encoding of the pages is UTF-8 already, so no change needed there.
- Set lang and xml:lang attributes on html-tag accordingly. Set it to the release language + script on every element surrounding release and track titles.

All I can think of. :-)

Simon

_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

[bogdanb]

On Wed, Feb 11, 2009 at 8:48 PM, Nikolai Prokoschenko
<nikolai@...> wrote:
> As most of you probably know, we are starting a new i18n effort for
> MusicBrainz. Since this list has been dead for almost three years now,
> I'd like to hear some voices from subscribers combined with their
> vision of i18n'ized MB -- what you need, what you'd like to be
> implemented etc. This is a long-term effort so but this means that
> almost everything can be taken into consideration.

Hi there! Just a couple of ideas to put on the table:

1) I had very good results with Launchpad's system of translations,
e.g. https://translations.edge.launchpad.net/democracy/trunk/+pots/democracyplayer

I haven't used others (except manual ones, i.e. editing a text file
and mailing it to the software's author), so there might be better
ways, but for this one I never encountered something that didn't feel
right.

AFAIK it's quite easy for external projects to use it, and they have a
lot of experience handling translations for a lot of programs to a lot
of languages, so it's probable they encountered and fixed any problems
that might appear.

2) The Romanian team for translations has what I found to be a very
useful community system. (All pages below are in Romanian, so they
might not make a lot of sense to most of you, but I'll describe them.)

https://wiki.ubuntu.com/RomanianTeam/Proiecte/Localizare/Ghid -
summary page linking the localization guide, how to configure your
computer (Romanian has some specific diacritics issues that I expect
won't be a problem for most), how to use Launchpad and where to
contact other translators.

Then there are:

http://i18n.ro/Ghidul_traducatorului_de_software - the translator's
guide, which is generic for all software. Includes things like correct
diacritics, consistent phrasing (for politeness levels,
personal/impersonal registers, gender, plurals (there are three forms
in Romanian), capitalization, punctuations, non-translatable words and
neologisms) and other guidelines.

http://i18n.ro/Greseli_frecvente - frequent mistakes

http://i18n.ro/Glosar - this is the best idea I saw: an interactive
glossary of frequent words that are non-trivial to translate. For
example, things like Cancel/Abort/Revert/Quit have close but different
semantics, and without a tool like this it's not easy to get everyone
to map them to the same Romanian words consistently. It's also a
constant issue whether words in English that have a separate meaning
for computers (e.g. mouse) should be translated or imported as a
neologism, and whether to do it phonetically or literally; French has
the academy to decide these, but in Romanian the academy is less
proactive, so there are also pages like http://i18n.ro/mouse or
http://i18n.ro/site that have automatic polls on which form should be
used.

I found all the above invaluable when translating things, and I've
never felt much was missing*. So it might be a very good idea to
follow this system. I imagine we'd get some piece of wiki to guide
translators in general, perhaps with this kind of tools made available
in a wiki, and then each language group would populate their own piece
of wiki with whatever's relevant for their language. Ideally for
Romanian I'd see a copy of or links to the generic tools I linked
above, and a couple of pages devoted to MusicBrainz terminology and
guidelines.

What do you guys think?

-- Bogdan Butnaru

_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

[Alex Dupuy]

Depending on the amount of MB developer resources that can be pulled in
on this, an alternative to using the Launchpad localization hosting
would be for MB itself to host a Pootle instance to manage the
localization and translation efforts.  It would be more work than just
throwing the existing gettext PO files up on Launchpad, but could
potentially be used not only for the Picard client and MB web service,
but even for documentation in the wiki.  It is also possible to directly
connect the Pootle server with underlying code repositories (e.g.
MusicBrainz SVN) - I think Launchpad can do this as well, but perhaps
only for code repositories that are also hosted on Launchpad, which
might limit that functionality to Picard.

The Pootle code is python-based, and the maintainers (coordinated by
translate.org.za) are in a burst of development as a result of Mozilla's
decision to use Pootle for managing i18n/l10n (Verbatim project).  The
next release of Pootle (1.3) uses the Django framework, and will
probably be available in late February / early March.

There are a number of communities that use Pootle as the primary tool
for managing their l10n efforts, notably OLPC (One Laptop Per Child -
the "$100" laptop for education in developing countries), OpenOffice,
Creative Commons, and as mentioned above, Mozilla (who are still in the
process of migrating to Pootle).  While the user interface and
experience are definitely not as slick as Launchpad (the Pootle UI could
legitimately be described as "quirky") there are advanced features, like
terminology suggestions or translation memory that can make it a much
more powerful tool than anything currently available on Launchpad.

Here are links to various resources related to Pootle:

Wikipedia: http://en.wikipedia.org/wiki/Pootle
Pootle main wiki: http://translate.sourceforge.net/wiki/pootle/index
Pootle localization of Pootle: http://pootle.locamotion.org/projects/pootle/
Mozilla wiki for Verbatim project: https://wiki.mozilla.org/Verbatim
Screencasts (ogg vorbis) showing use of Pootle:
http://l10n.mozilla.org/pootle/screencasts/
List of live Pootle servers:
http://translate.sourceforge.net/wiki/pootle/live_servers

@alex


_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

[Nikolai Prokoschenko]

Hello,

> - Make pages / recurring elements or the strings from there
> translatable.

Done on the TT branch, possibly needs refinement.

> - Make some of the data in the database translatable (the
> table of language and country names

This is planned and I think we could wait for NGS to happen to bring this
on.

> - Localised number and date formats (remember: this is country-based,
> not language-based).

Is on my list, will probably use CLDR for that.

> - Page layout needs to be rtl'able.
> - Page layout has to cope with strings which are much longer / shorter
> than the ones it was originally designed for.

Should probably be no problem with a bit of fine-tuning, but we'd need an
RTL translation for that first.


> - Evaluate Accept-Language
> HTTP headers and do geo-targeting (there should be web-services for
> that) first to get an initial selection of language + country.

Accept-Language is already done, geo-targeting I would rather not
implement since it might screw up badly (possible ethnic wars, etc ;))

> - Somewhere on every page there should be a selection for language and
> country. This overrides the initial selection. For unregistered
> visitors, this sets a cookie. For users who are logged in, this could
> change an account setting.

Planned.

> - Set lang and xml:lang attributes on html-tag accordingly. Set it to
the release language + script on every element surrounding release and
track titles.

We'd need this information for each track first, but yeah, it's a good
idea.

Nikolai.


_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

[bogdanb]

On Thu, Feb 12, 2009 at 6:14 PM, Alexander Dupuy <alex.dupuy@...> wrote:

> Depending on the amount of MB developer resources that can be pulled in
> on this, an alternative to using the Launchpad localization hosting
> would be for MB itself to host a Pootle instance to manage the
> localization and translation efforts. It would be more work than just
> throwing the existing gettext PO files up on Launchpad, but could
> potentially be used not only for the Picard client and MB web service,
> but even for documentation in the wiki. [...]
> While the user interface and
> experience are definitely not as slick as Launchpad (the Pootle UI could
> legitimately be described as "quirky") there are advanced features, like
> terminology suggestions or translation memory that can make it a much
> more powerful tool than anything currently available on Launchpad.

It's too early to have a serious opinion on each approach in
particular, but I want to stress that I think making things easy to
use _is_ very important in this context. Especially for things that
are a bit niche, like MB.

There are quite a few programs on Launchpad that I've translated in
one go, simply because I just happened over a link and I was in a
tinkerish mood and it was really easy to at least start working. It
even happened for a program I had never used before, as a sort of
encouragement.

There are also a few programs I wanted to translate and gave up
because it took too long to figure out how to start. I even went
through the trouble to register on Pootle and check it out, and I
couldn't figure out in five minutes how to start. On Launchpad it
takes about ten seconds once you're registered.

Of course, I had the exact same problem with Launchpad a couple years
ago, the first time I wanted to translate something. It improved, and
I expect Pootle will too. But a few years count. If it's possible to
just put the translation files _now_ on Launchpad (or anything easy to
use) and start a translation immediately, at least for some parts,
that would be very useful. (I also expect more people to be familiar
with it, as an added bonus.) And of course, if Pootle (or something
else) allows us to do more but with more work, nothing prevents us
from taking our time with that work, and when it's ready import
whatever translations are already done on Launchpad and continue from
there.

-- Bogdan Butnaru

_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

[Simon Reinhardt]

Wow, the planning is much further than I thought then. :-)

Nikolai Prokoschenko wrote:
>> - Evaluate Accept-Language
>> HTTP headers and do geo-targeting (there should be web-services for
>> that) first to get an initial selection of language + country.
>
> Accept-Language is already done, geo-targeting I would rather not
> implement since it might screw up badly (possible ethnic wars, etc ;))

Well, for proper l10n you need location information. I like the way YouTube does it - if you access the page without any cookies it redirects you to a country-specific domain and then tells you what it thinks your country is, doing that in your language. Well, they way they do it, big box appearing every time, is a bit annoying, but anyway - if gives you choice and full control over what's going on. What I think is weird though is that they don't really use the country information for number and dates formats, that still follows your language setting. So they only use it for some other l10n stuff, maybe it influences their recommendations or what terms of service apply or something, I don't know. But, just because I'm in a different country at the moment and therefore have my cookie for YouTube set to that country doesn't mean I want that country's number formats, so maybe it's not that bad.

I'm not sure how good a guess about formats you could make, just based on the language. I can imagine that American date formats would annoy/confuse British people. ;-) But since the country-variant of the language is often included in the language tag sent with Accept-Language (en-gb -> "British English"; not "English, Britain"!) you could probably make a pretty good guess. Luckily you don't have to deal with currencies anywhere in the interface yet. :-)

Simon

_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n

[Nikki-21]

Nikolai Prokoschenko wrote:
> As most of you probably know, we are starting a new i18n effort for
> MusicBrainz. Since this list has been dead for almost three years now,
> I'd like to hear some voices from subscribers combined with their
> vision of i18n'ized MB -- what you need, what you'd like to be
> implemented etc. This is a long-term effort so but this means that
> almost everything can be taken into consideration.

I think we'd need the ability to set fonts. Han characters are unified
in Unicode, so the only way to get the right style of characters for CJK
languages is to change the font.

I'd also like to see locale based sorting. I think that might be harder
though, doing that with postgresql is quite awkward IIRC.

Nikki

_______________________________________________
MusicBrainz-i18n mailing list
MusicBrainz-i18n@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n