[Mailman-i18n] Me and Mailman

[David Planella]

Hi Eirik,

I'll answer the bits I can and I'll leave the rest to others more
knowledgeable on the other questions.

2010/5/5 Eirik U. Birkeland <eirbir at gmail.com>:
> Hi. Reacting to the point ‘Please introduce yourself, so we get to
> meet you, and to find out what you are going to contribute’ I want to
> say that my name is Eirik U. Birkeland, and I come from Norway. I have
> already (locally) started a Norwegian Nynorsk (nn) translation of
> mailman, and am also able to help out with the existing Norwegian
> Bokmål (nb) one. I have been involved with several free software
> translation projects during the past 3–4 years or so, among them KDE
> and OpenOffice.org.
>
> Now for a few questions/comments I wanted to raise:
> 1. Can somebody formally start the process of adding Norwegian Nynorsk
> (nn) as a language in Mailman?
>

You'll find more info on the process here:

  http://wiki.list.org/display/DEV/Internationalization

You've already done the first step in introducing yourself on the list
:), and I think now the next one is to sign the disclaimer assigning
the copyright to the FSF, so that they can maintain it and your
translation can be used in Maillman.

You'll find more info here (that's also explained in the wiki page above):

  http://translationproject.org/html/whydisclaim.html

If I've forgotten any step, I'm sure Barry, Mark or others on the list
will chip in.

> 2. Is there demanded a certain amount of work to have a SVN account? I
> have one at several of the other projects I’ve been involved with, so
> I’m quite familiar with it, and since there is noone else for
> Norwegian Nynorsk, so…
>
> 3. With the current information in mailman, it gives me and every
> other user the impression that Norwegian Bokmål (nb) is the only form
> of Norwegian (no), as it is called the latter. Please change the name
> to Norwegian Bokmål and the language code to nb.
>
> 4. I saw Barry Warsaw write in another email to this list that:
> ‘Ultimately we're going to move all translations to Launchpad, but
> probably only for the Mailman 3 series.’ I just wanted to say that I
> would *strongly* recommend you not to. The list of cons with the
> Launchpad translation system is longer than you could possibly
> imagine.

If the list of cons is so long, I'd like to ask you to share them on
the list, so they can be evaluated. I can only see pros, but then
again, I'm a bit biased, being a long time user of Launchpad
Translations, but also of many other systems, such as the GNOME
Translation Project, Pootle, the Translation Project, the several
methods Debian use, and also many projects in which PO files are
simply sent on a mailing list and committed on a repo.

I think having a translation management system (just any!) for an Open
Source project, as opposed to having to fetch PO files from a repo and
sending them to the list is a big improvement for both translators and
developers, and it just speaks for the maturity of a project. Here are
my general pros:

* Translators can work almost independently from developers
* Less work for developers and maintainers
* Less technical skills involved for translation, lower entry barrier
for contributors

I find last one the most important one. While some people will argue
that making the entry barrier for translation will result in higher
quality translations (I've heard that many times), I'm of the opinion
that artificially raising the entry barrier always results in less
contributions, regardless of the quality. Quality in translation can
only be achieved by established review practices in the translation
teams, and that is independent of the translation tool being used.
Having an advanced translation management tool plus using QA practices
can only bring advantages.

As for the pros specific to Launchpad Translations:

* As Mailman is already using bzr for development, the bzr integration
with translations can be taken advantage of. This includes:
** Automatic translation imports: translations are imported
automatically from a given code branch
** Automatic translation exports: translations are exported daily
(read automatically committed to a branch of choice) when translators
do their work
* The translation of several project versions can be maintained from
the same central location.
* Translations are shared between the several different project
versions. That means that translators don't have to complete
translations in all versions or fix typos or spelling mistakes over
and over: translate in one series (version) and your changes will be
propagated instantly to the identical messages in all other series.
You can also choose identical messages to diverge between series.
* A simple, clean UI that is easy to use for new and experienced contributors
* Compatibility with traditional translation methods: if you prefer
translating offline, you can simply download a PO file, translate it
with your favourite editor, and upload it again. You don't need access
to any repo or need to depend on someone else to upload it for you.
* Statistics are shown in the UI to better track your work as a
translator and help setting goals.
* Different permission levels: as Mailman requires you as a translator
to have signed the disclaimer, only those people who've done that will
be able to translate it. Launchpad supports this as one of its several
permission policies, which is the one recommended for most projects
anyway. I myself find that an Open translation policy, without any
kind of peer review, be it in Launchpad or in any other project, does
often lead to lesser quality translations.
* Basic review capabilities: you can mark a string as "Needs review"
and save it, and it will be stored as suggestion, but not submitted
until someone else explicitly reviews it and accepts it (or provides
another suggestion).
* Global suggestions from all projects translated in Launchpad. While
not functioning as a proper translation memory, this is quite powerful
in terms of using the work of the huge pool of translators in
Launchpad. Quite often translating is only a matter of reviewing,
pointing and clicking.

> In Norway we have seen several high-quality translations
> being virtually ruined by it.

That is related to the permissions chosen by each particular project.
Launchpad offers several translation permission levels, from very open
to very restrictive [1], and it's up to the project maintainers to
choose.

I do agree that choosing Open permissions is not the best option, and
often what translators do is to ask developers to choose a more
restrictive permission assigned to a set of language teams, who are
ultimately responsible for translations in their own language.

For the record though, when using Open permissions, what I've seen is
more wrong translations or with typos being submitted, rather than
overwriting current ones.

> Translating over the Internet is a
> *much* slower and more ineffective way of doing it than using an
> offline translation software, like e.g. Lokalize or Poedit.

As mentioned above, you can do exactly this with Launchpad
Translations, you just download the PO file, translate it offline with
an editor, and upload it again.

> Using just
> ordinar .po files with a statistics system like the one for KDE [1] is
> by far a better solution IMHO.
>
> [1] http://l10n.kde.org/stats/gui/stable-kde4/team/
>
> Best,
> Eirik U. Birkeland

I won't argue now on what system is best (other might find Vertimus in
GNOME better, other Scripty and stats in KDE better, other the stats
for Mozilla projects better). I do believe though, that any online
translation system (be it Launchpad, Pootle, Narro, etc.) can only
ease the work of translators, which for me is the ultimate goal in
making the process of providing better natural language support to
applications easy.

Cheers,
David.

[1] https://help.launchpad.net/Translations/YourProject/PermissionPolicies