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 <[email protected]>: > 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 _______________________________________________ Mailman-i18n mailing list Posts: [email protected] Unsubscribe: http://mail.python.org/mailman/options/mailman-i18n/archive%40mail-archive.com
