-
The GUADEC diaries — chapter 2
-
Wireless connection is rare in Birmingham, so I’ll grab this opportunity to post a quick update.
-
Had a meeting with Danilo Šegan (Данило Шеган) of GNOME L10n fame and Carlos Perelló Marín of Ubuntu, Launchpad/Rosetta fame, and discussed handling of upstream translations. It’s a pretty important issue which everyone would like to see tackled, but there are many technical details that need addressing, like for example, downstream patches that alter the module’s translatable strings (the need only downstream translation, requires coding), security (sigh), and coordination with/review from upstream translation teams (if they exist).
Danilo and I talked also about translate.fedoraproject.org, damned lies and Transifex. Both of us would like to keep the codebases close to each other, but without breaking or enforcing anything. This is basically my responsibility, but transifex adds a bunch of stuff on DL’s object model, and requires the data to be updateable (ie. XML files are problematic), so we should solve these in DL too. A port to TurboGears will make the project more maintainable.
-
Talked a bit with Colin Walters and Bryan Clark about Mugshot’s i18n. There are a bunch of different technologies in the project, so it’s not just a matter of a patch submitted. The Python web pages might be the easier of the three targets (other two are the server and the client).
-
Had a cool discussion with a Fedora OpenOffice.org hacker/maintainer about the way OOo handles locales and languages. There are many requests to have OOo override the session’s locale, which imply to have OOo behave differently than all the other desktop apps. This will only increase the confusion and if the problem is solved, it will only be so for OOo. Also, OOo spellchecker ideas about fine-grained language detection are again something that ideally would be solved desktop-wide and not just in OOo. Having the “keyboard layout” define what the language of the text written is, again isn’t a one-to-one relationship; this could work, but only if it was just a suggestion to a guessing engine, and not a true binding between the two. Doing something that makes sense is important.
Update, 2 hours later:
-
After my talk, David Glassey from Debian approached me for discussing whether it’s possible to use Transifex in Debian. The answer is definitely! — the whole idea behind transifex is to give the ability to any translator community to contribute directly to a remote VCS, thus bridging the gap between the translation commuinities. The more downstream communities get connected, the better for everyone: more language coverage, higher quality.
Of course, each bridging attempt brings the possibility of conflicts. People have different opinions on how a phrase should be presented in a different language, and so this is an issue that might come up at some point. Let’s hope a discussion will always bring an answer, make everyone happy, and make the new gate work constructively. :-)
Talking about gates, Transifex could also be used by an individual translator on his workstation, as a gate to all the projects he is submtting translations to. One can set it up with his SSH keys, get presented with all the projects he has access to, and use it to commit contributions instead of the command-line VCS tools. For those who want to quickly do something without any strange VCS voodoo, they can simply grab the PO file from the statistics page and commit it through transifex in two clicks.
Other related posts:
-
-
πριν το μεσημέρι, Πέμπτη 19 Ιουλίου 2007
[ Fedora, GNOME ] |
Σύνδεσμος
| Σχολιάστε!