No idea if this really matters, but we might have to handle different formats here too - http://trac.tspre.org:8088/projects/...ew/po/de_DE.po (OK, that's simply taken from upstream so I hope it won't matter for us) has the msgid's in en_US so you can simply translate them to msgstr's, while http://trac.tspre.org:8088/projects/...ew/po/en_GB.po and probably all Maemo software has its msgid's as "technical strings" like "window_blah_do_this_and_that" which means that you have to always take a look at a second file (the msgstr's in en_US) to translate these strings to another language. Makes it a little bit more complicated and error-prone.

We had similar issues at OLPC with some of the files. We simply asked people to enable English (US) as the alternative language from their Pootle control panel, so that they could see the en_US translations while translating into their own language.
However, this did not work for offline translation, so I wrote a small script which would insert the en_US translation as comments for each string in the PO file itself.

Handling strings in mobile devices is a bit more complex since generally the space is more limited. This is a reason to use tools that allow you to see the translations in the UI itself. Therefore the input could be done from a localization tool related with the SDK where you would edit directly on top of the UI.

Hi all. I'm one of the developers of Transifex. It's great to hear that Maemo
is considering Tx as its L10n platform, since we built Tx with communities
exactly like Maemo in mind.

For the folks who haven't heard of Transifex before, here are a few
introductory links:

LWN.net article
http://lwn.net/Articles/325311/

Overview of Transifex and the challenges of FOSS L10n:
http://blog.transifex.net/2009/03/le...nguages-bloom/

Feature list of Transifex 0.5
http://docs.transifex.org/releases/0.5.html

One of the challenges with Maemo, is that we have content originating from
various sources. Like Linux distributions, translators will like to
contribute to projects that might be hosted internally or externally. Some
developers might host their code/translations on various types of versioning
systems, and some of the UIs might be hosted on the servers of upstream
projects. Transifex was built in a way that developers will have the freedom
to choose the workflow that works best for them (repository location, VCS
type, branching, releasing), while at the same time translators enjoy a
dead-easy interface to find the translation files they'd like to contribute
to.

The platform chosen should support the above and avoid putting an extra burden
of copying translations to the L10n server, possibly losing sync with the
upstream repo, etc. This will only get worse when we have multiple branches
and releases. If we want to also allow folks to contribute directly to the
upstream VCSs, then I wouldn't like to be the guy who is asked to do the
merge. =)

It's also important to note that a lot of the very productive contributors
prefer existing high-efficiency workflows. This includes the use of offline,
desktop tools. This allows them to be more efficient in translating,
run their own toolchain and produce results of better quality. An L10n
platform should compliment and augment this workflow.

From my experience through GNOME and Fedora, translators prefer their desktop
applications for large modules and a Web UI for smaller ones. A powerful
command line interface can lower the barrier to entry and reduce the
necessity for a web UI substancially (`tx get-files italian` and `tx
send-files`). Such a CLI should land in Tx's features in a few months.

Choosing an L10n platform is no easy job. It's an investment, and because it
touches a large number of people (including translators and developers
themselves), a tough one. Here are some of the Transifex features I believe
the Maemo community should note:

- Tx was built ground-up for projects like Maemo. I suspect that most of the
roadmap items will be used right away by the Maemo translators and
developers, so the value will only increase in time.

- Tx was built ground-up as a platform to be adapted, extended, themed, and
integrated with other systems. Continuing qgil's example: Want to edit
a translation from inside an IDE or a desktop app? It should be an
API call away.

- Tx places an emphasis on workflow and collaboration, and aims to capture the
workflow of the whole community (translators, developers, release
engineers). It includes support for real-world mix-matching of translations
in multiple collections, releases, independent projects comprised from
multiple branches potentially hosted in various repos.

- Transifex has a cool name. =)

Kidding aside, some of the other tools mentioned in the thread have been quite
longer than Tx. We've had the chance to study their strong points and avoid
their weaknesses when building Tx. Our team at Indifex was recently formed,
and we're excited to be working in making Tx a full-featured open translation
platform, with which these tools can interoperate if they choose so.

The basic point here is tha Tx is aligned more towards being a L10n platform
rather than a tool to edit translation files from the web. Thinking things
from the architectural side, a web-based PO editor can sit 'on top of'
Transifex and request all the low-level bits from Tx. (read/write files, get
project lists, ACLs, etc).

Here are some of the features the Transifex crew is currently cooking:

- Support for reading translation files from tarballs
- Rich support for teams per project/component/collection/release
- Integration with Bugzilla
- Pluggable simple web-based editor for easy editing of a small number of
strings
- Investigate how Pootle could work _on top of_ Tx. Pootle is extremely good
in supporting translator-specific things like glossary/terminology, memories
etc, and Tx can serve as its 'Virtual Filesystem' and repository management
backend.

And... that's it from me. Whoo, that was long.

Fire away any questions. Or swears for the long post. =)

There are different problems combined here:

- New strings vs old strings in maintenance mode vs old-old strings. The solution is that English strings go as soon as possible to enable localization, followed probably by the rest of official translations as soon as they have gone through the internal revision.

- New system strings that could come together with SDK pre-releases vs new applications strings that at least now would need to be treated differently since they would come no sooner than a new release launch.

- Localization testing taking into account bugs.maemo.org and getting the feedback in the best time to implement the changes.



Agreed. However, I also think that the way to give feedback about the official languages should be filing bugs. Those texts have gone through internal revisions already, are tied to a Nokia terminology and any changes go through a revision equivalent to a pacth submitted (only simpler to test). Offering a e.g. web interface to modify those strings and propose changes would give the impression that anybody can get changes committed easily. This has the potential of creating a lot of unproductive noise and discussion, just as if you would offer an easy way to submit changes to the icons and design layout.

I'll try to shed some more light on a few key assets of Transifex, which I believe are important for Maemo to go forward with its L10n infrastructure.

- Easily adoptable workflow: The core Transifex featureset works well with various workflows in big projects like Maemo. It has worked quite well for Fedora and both translators and developers have been very happy with it. Maemo folks will be able to start working right away with the new infrastructure, since it complements it rather than substitutes it (comments by Richard Hughes, Lennart Poettering).

- High development pace: New features are being pumped on a weekly base (see activity at http://transifex.org/timeline). As the team grows in order to reach our goals as quickly as possible, this will most likely increase further.

- Low feature turnaround time: Feature requests are turned into working code and shipped releases quickly. This has been instrumental in the happiness of our developers and translators (comment by Paul Frields).

- Additional features: Once we identify any additional requirements from the Maemo community, we can proceed to assessing their importance, position them on Transifex's roadmap, and then go on and turn them into code.

- Commercial support: Indifex is a fresh team looking for potential partners and working with Maemo is important for us. We're sensitive to requests, we can quickly implement any additional features needed, and we can support the community in maintaining a top-notch L10n infrastructure, similarly to what we're doing with Fedora.

- Long-term Vision: We believe enterprises like Nokia can find improvement in their localization process. Our goal is to disrupt the legacy localization process and making translation crowdsourcing a lower-cost and higher-quality choice. Maemo can show Nokia the way translations should be done.

Unless someone comes up with a better proposal, Transifex + tool to localize on top of emulated UI looks like the most convenient approach.

Web interface is a nice to have because of the lowest entry barrier. However, in a mobile interface seeing the strings in "real" screens is very important, so the tool (that will be provided by Nokia) needs to be there anyway.

A quick note to announce that Transifex 0.6 codenamed "Apocalypse" was just released, after one month of development.

This release is packed with new features, and we're pretty excited about some of them, like the support for receiving notifications on file changes and translating tarballs.

Here's an overview of what's new in Tx 0.6:

• Tarball repositories
• User Notifications
• Multiple files per language
  
• Internationalization support
• Translation file archives
• User Interface improvements
  • Untranslated components list
  • More RSS feeds
  • Easy file selection for editing
  • Sortable statistics tables
  • Commit improvements
  • Better whitespace usage
    
• Under the hood changes
  • Revamped settings mechanism
  • Improved abstraction for repositories
  • Improved languages support
  • Action logging
  • Standard code directory structure

A full list of the features with details and screenshots, and a list of bugfixes can be found in the release notes, at:
http://docs.transifex.org/releases/0.6.html.

Can we decide whether the community localization infrastructure in maemo.org will be based in Transifex? If we can, let discuss and agree. If we can't, what is missing?

The Maemo Summit is a good chance to invite glezos or a maintainer of whatever tool we choose to have a presentation and a BOF to discuss about features, customization, implementation...

From Mer POV, I vote for Transifex. Active development and active developers represented here.