Community translations of Maemo software
 

One of the 2010 objectives is community localization:

http://wiki.maemo.org/Objective:Community_localization

The goal is to allow the organization of translators in language teams in order to produce community supported languages for Maemo. This would include the official releases and the tool could be open to community/third party applications as well.

After some research and thoughts, I think we could have a look to http://transifex.org/ an open source tool created precisely for this kind of purpose. It is being used by the Fedora project: http://translate.fedoraproject.org/

A strong candidate would be also https://translations.launchpad.net/ - planned to be open source later this year. A drawback seems to be (please correct me if I'm wrong) that Rosetta is part of the whole Launchpad infrastructure and it's not easy to detach.

Re: Community translations of Maemo software
 

Sitenote: While making it easy for translators to contribute is the most important thing (in GNOME's "Damned Lies" tool you still have to commit to SVN/git manually as it's not integrated into the platform, but planned as far as I know) I wonder if any of these platforms also create&update (on-the-fly) automatically a glossary for each language and pre-fill in proposals for translators (maybe even based on language glossaries already existing for GNOME, KDE, Mozilla and Microsoft), because lack of consistency is one of the biggest issues I've seen in GNOME's translations in the last years. I think Launchpad did this partially, but it's been a while that I've taken a look at it (and I haven't worked with Transifex yet).

Re: Community translations of Maemo software
 

Will this only be for providing support for unofficial languages, or can improvements be offered for official localizations? Nokia's English strings are usually a bit . . . weak (and occasionally offensive—see the "You loose!" debacle). It'd be nice if we could get ahold of the strings early enough before a release to help improve them (since poor strings tend to say a lot about a platform).

Re: Community translations of Maemo software
 

I agree with these kind of tools! And I'm available for translation into Italian language.

Re: Community translations of Maemo software
 

I guess such tool should be used to file bugs / enhancement requests about the official languages, yes. How early the strings can be made available would depend on factors such as open/closed apps and product launch vs sales start. Good to raise the suggestion now. I will ask.

Re: Community translations of Maemo software
 

I tried Transifex for a bit - just summarizing my immediate experiences with it:

* Easy to set up, had it up and running within 15 minutes
* No online .po editor - it requires a translator to download a .po editing tool, which causes the workflow to be download, modify, upload
* Close integration with SVN/CVS/BZR, but failed to get it to actually commit to a repository - when you upload a translation you commit to the repository.
* OpenID support, which is nice.

It is a bit like a fancy interface to a source code repository, which shows the statistics of how many strings are translated, but doesn't seem to support any collaboration features beyond locking a translation and uploading/downloading translation files. It does not even tell you what strings are represented in one but not the other.

My showstopper problems with it:
* A translator shouldn't be required to download tools to help out - it limits the amount of people we can crowd source from
* It doesn't offer any kind of connection between the translations / .po files, even if there's a lot of things that could be done to make translation an easier experience.
* It would be better to offer an administrative "merge translation" capability, than the current "upload straight to repository" method.

I've put up a test instance of Transifex up on http://trac.tspre.org:8088/ - use login guest, password guest, - it is based on the Mer project, so there's pre-existing Hildon etc strings loaded into it.

Re: Community translations of Maemo software
 

Yeah, I don't see this working (it certainly hasn't worked so far). Nokia tends to take at least a year to actually take useful action on things filed in the bug tracker (or three, or never. . . .), and by that time the strings are often obsolete anyway, and a whole new set of (broken, poorly written) strings have been shipped.

No, if there's any chance of the community managing to help fix these, we need to be able to get in there before every thing's set in stone.

Re: Community translations of Maemo software
 

Possible alternative:

http://pootle.locamotion.org/

Seems straightforward to start translating for a user - register, activate, log in, and translate - easy to find where there are lacking strings. All through a web page.

Re: Community translations of Maemo software
 

Having used all of the options already mentioned here for the translation of several different open source projects, I have to say that Transifex is in my opinion at the very top of my list. From the perspective of the administrator who is setting up a project for localization for the first time, the fact that you do not have to create several accounts for the given versioning control system is a major plus, specially for larger projects with many different teams and collaborators. Most projects will create these accounts/credentials on a as needed basis and try to keep them to a minimum. During "peak" season, usually right before a release, having only one (or a couple) person with credentials to make the commits could lead to a bottle neck if this person is not available for whatever reason. Transifex allows for the creation of a list of "trusted" collaborators who have direct access to the commit process without the need of a corresponding account in the version control system.

About your first point, I actually think that the fact that you only need a text editor, regardless of what operating system you're using is a major plus. :) No tools to download but the po file itself. I wasn't sure about your second point, but about the third, you could use roles to control the workflow, so that people can upload their work and then be reviewed by someone.

I don't remember right off the top of my head if Tx provides a diff of the uploaded file compared to the original one, but the Tx guys are very quick at turning feature requests into functional code. :)

Re: Community translations of Maemo software
 

Hmm - your problem seems to be familiar ;-)


I have been facilitating/leading the largely volunteer based l10n/i18n efforts at One Laptop Per Child for the past year and a half, and we have been really happy with Pootle.



Some of the reasons we chose it (at that point) were:

Low Barrier to Entry: We wanted to lower the barrier to entry for potential translators as much possible (especially since we were targeting languages/locales like Dari, Aymara, Pashto, where technical computer knowledge could be minimal). If you have a internet connection, translation using Pootle is extremely easy. We had a primer which covered most of the process: http://dev.laptop.org/~sayamindu/pootleforxo2.pdf We managed to go from around 2 supported language (>80% translation) to 19 supported in less than a year. Of course, this was largely due to super awesome translation community that helped us, but I think the relatively lower barrier to entry helped us as well (someone with an internet connection could just register on the site, and start contributing). Even if someone cannot translate directly due to ACLs set by a language team coordinator/lead, one can always submit suggestions which can be reviewed and accepted later by other members in the team.

Flexibility/Choice: Pootle gave the option of download and subsequent upload of PO files (like you would do in Tx), as well that of online editing of PO files using simple web based UI. We were dealing with potential regions with very little connectivity, and wanted to be as flexible as possible. This turned out to be a life saver during a Aymara translation sprint in Bolivia, where someone volunteered to collect all the translated PO files, drive to the nearest place with an internet connection, and upload them.

Support for Different Formats: Support for different formats was yet another major issue for us. Eg, for some deployments we sent out PO files converted into CSV files, which were edited using Spreadsheet software, and were finally subsequently converted back into PO files with the tools which come with Pootle's backend - the Translate toolkit (the process required a bit of manual tweaking though, but it proved to be a life saver at times).

Built in tests: Pootle has some nice built in tests which an administrator can use to ensure quality. These check for some common mistakes which are done during UI translations. A description of the various tests is at http://wiki.laptop.org/go/Localizati..._within_Pootle

Assigning tasks, etc: Pootle has some nice tools for the coordinator of a translation project. One can assign tasks, etc using the web based interface. The OpenOffice.org folks (who use Pootle, btw) have put up a nice guide on these features: http://wiki.services.openoffice.org/...nslation_Leads

Support for multiple VCS-es/repos: Pootle supports all the major version control systems, and we wanted to make sure that if someone did not use Git (OLPC's preferred VCS), we could still accomodate them.

Support for alternative languages: This was a bit of special requirement for us. Our Aymara translators wanted to see the source strings in Spanish, as they knew little English. So with a little bit of effort we managed to add this feature to Pootle where you could choose an extra language, and while translating using the web interface, you would see the translations for that particular language as well (if they already existed in Pootle - which was not a problem in our case since we had nearly 100% coverage with Spanish). I believe this feature exists in Rosetta as well. Subsequently this feature was polished a pushed upstream (with a set of other features as well) by a GSOC student.

Grouping of files: We could group PO files by category, which helped us to prioritize translations. The core UI and libs could be translated first, and then the Activities.

Adoption by other leading FOSS projects: OpenOffice.org was already using it, and at that point there were talks about Mozilla folks adopting it as well. The OpenOffice.org people are still using it, and the Mozilla people have been also contributing to the code base significantly (they have proposed some radical UI changes). I believe the plan is still on for the Mozilla folks to adopt Pootle as the base of their l10n infrastructure, though the schedule seems to have slipped somewhat (https://wiki.mozilla.org/Verbatim)

Glossary/Terminology Support This is extremely important if you want to ensure consistent translations (eg: you should try to ensure that Open is translated as Foo everywhere, and not as Foo at one place and Bar at another). Pootle supports glossary, and here's how to use them: http://wiki.services.openoffice.org/...Glossary_Guide and http://translate.sourceforge.net/wik...ology_matching There are tools (which are parts of the Translate toolkit) which lets you generate a glossary for your language from existing translations as well. The tool to do this is poterminology, which is documented at http://translate.sourceforge.net/wik.../poterminology

Access control: The language team lead can set default permissions, as well as individual permissions for team members. The permissions range from ability to submit suggestions to reviewing them and actually translating terms, to committing files and assigning work.




Of course, not everything was not perfect, so here's a list of Pootle disadvantages that we found out/faced:

Slow and resource hungry: With large files (eg: we had individual files with almost 4500 strings), Pootle can be excruciatingly slow, especially if you are trying to merge something or upload something. This process would take up significant CPU, as well as memory. However, with newer version, this has been dealt with partially (better caching of PO file statistics, indexing using Lucene/Xapian, etc). Currently we are evaluating moving Pootle to a newer hosting facility at SugarLabs, and I'm pretty happy with the new version's performance.

Poor intra-team communication: A language team lead had no way of communicating with the members of the language team via Pootle, and this is true for the reverse as well. However, I think this feature can be easily added with some amount of effort. I have often manually helped language leads by providing them with a list of all the people who have signed up in Pootle, and chosen the relevant language from their settings panel.

Requires reminder for committing: Sometimes language team leads forget to commit the files, assuming that just translating the files would be enough. It has been suggested that some kind of visual cue (marking a file as uncommitted) on the web interface can be helpful, but we have not successfully implemented this feature yet (mostly due to lack of time).

Complicated "backend": We have a significant number of files in OLPC's Pootle installation. This needs to be managed, and I have had to create a set of scripts and cron jobs to ensure that things stay in order. I'm not sure what your plans are, but Pootle does require some amount of manual attention, love and care, which might necessitate a l10n infrastructure team (I don't mean a large team - at OLPC, upto this point, it has been a one person team.. which was me (apologies for the shameless plug :-) But now, as we are scaling upwards with Sugarlabs, we have started to build a l10n infra team, for adding redundancy and reducing the bus factor, if not anything else)




Hope that helps in your evaluation. I do not have particularly anything against Tx or Rosetta, and feel that they are incredible tools. I just wanted to share our experiences about what looks similar to what you are trying to achieve.
I'm terribly bad at documenting the things I do, but I had created a small description of the workflow that we use: http://wiki.laptop.org/go/Localization/Workflow
A list of the important Pootle features is at http://translate.sourceforge.net/wiki/pootle/features

Re: Community translations of Maemo software
 

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.

Re: Community translations of Maemo software
 

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.

Re: Community translations of Maemo software
 

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.

Re: Community translations of Maemo software
 

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. =)

Re: Community translations of Maemo software
 

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.

Re: Community translations of Maemo software
 

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.

Re: Community translations of Maemo software
 

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.

Re: Community translations of Maemo software
 

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.

Re: Community translations of Maemo software
 

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...

Re: Community translations of Maemo software
 

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

Re: Community translations of Maemo software
 

As someone that's managed localization for a few projects, I would say that we should try Transifex. It looks like it has all the tools needed for the job.

Re: Community translations of Maemo software
 

By the way, I can't stress enough the need for a way to see the strings in an emulated UI as mentioned earlier in the thread. A lot of people that have never worked within localization on smaller formats such as cell phones don't realize how much MORE screen real estate is used by translations in comparison to the original English strings.

I've worked on 10 different games for cell phone platforms which were translated into about 15 different languages and 6 or 7 encodings. Just because English fits there doesn't mean other languages will.

As a general guideline, French strings will be anywhere from 50% to 80% longer per string and German is between 80% and 120% longer per string. (Germans seem to enjoy joining together multiple words into one long 20 character word for some reason.) Most of the other languages shouldn't be as long.

None of my work projects had the ability to directly view strings in our game UI, unfortunately.. so it meant we had long periods of going back and forth from testers to localization until each string worked. Let's not allow that to happen in Maemo, please.

Re: Community translations of Maemo software
 

Maemo Summit? Woohoo, I'd be thrilled to be there and discuss all our localization needs (new features, Maemo-special ones, integration with developer and desktop tools).

On a sidenote, we just released 0.7 Release Candidate 1 with some nifty features:

• Online Translation Editor
• More control to Project Maintainers (register and edit your projects, control who can submit files)
• Submissions via email
• User Profiles w/ Google Maps integration
• Integrated support for Publican-like (multi-POT) projects

For more information, including links to pre-built and preconfigured ISO, VMware or EC2 images (x86 and x86_64), take a look at the 0.7 release notes.

About integration with other tools, we bootstrapped the base for an API, as the base for such support.

Re: Community translations of Maemo software
 

So is there anything happening on this front yet? Is it still too early to make a decision? Has anything advanced at all?

I hate to be a pain, but I'm just sick of things being discussed, decided upon and then forgotten. (This line is just a general reference to things I see in my life, not anything having to do with Maemo in particular.)

If nothing has changed since this topic started, what needs to be done on my/our end to make this happen? What else can we do to push this along and make community-based translation/string fixing a reality for Harmattan?

Re: Community translations of Maemo software
 

I'm also interested how this is going. I have done also some localizations and I would like to see this going forward.

Re: Community translations of Maemo software
 

A good scenario would be:

- The Maemo community decides that Transifex is the way to go. Council + maemo.org dev team explicitly agree.

- Planning phase starts: what concrete objectives do we have? what needs to be done in maemo.org? does Transifex need any customization or extra development? does this project need any extra funding from Nokia?

- A plain Transifex instance is available in a maemo.org URL so we all can start playing with it. For instance Extras apps can see how to use it. We would get the Harmattan program to play with it as well. Maybe something can be done with Fremantle at a test/unofficial level.

- The Maemo Summit would be a place to meet and make some concrete progress.

Re: Community translations of Maemo software
 

Guess I'll put in for sponsorship, then.

Re: Community translations of Maemo software
 

I've decided to split this up into several task proposals for Maemo's sprints. I've created the first task proposal and will be writing up an overarching Wiki page covering all the tasks that will need to be pushed/done to make Community Translation a reality.

You can find the first proposal here: http://wiki.maemo.org/Task:Evaluate_Transifex

Please feel free to let me know what you think or if there's anything else that you feel needs to be added to it.

Glezos, I would really appreciate your help and some comments on this so we can push this forward.

Re: Community translations of Maemo software
 

What's the reason for the need for an upfront decision? I've not read every post in this thread in-depth, is there a licence cost for Transifex that Nokia'll be paying for? Is there an enormous investment in maemo.org infrastructure which will distract the gang-of-four from their other tasks?

What we need is someone passionate to pull together enough interested people and technology to provide a mechanism for community translations of their app, which gets used by someone else, which gets used by someone else. Example apps would include Conboy (where conny's been very good at including translations from the community submitted through tmo).

I can't see a dictat coming down that "Transifex is the community's preferred l10n/i18n solution" working, when it's not been trialled by the community.

Come to me with actual results and the council'll make a decision for the community. However, unless we can't avoid it; we're not in the business of making decisions for the whole community (or pretending to).

Re: Community translations of Maemo software
 

I think you might have jumped the gun a bit here. Quim just skipped the "community tests Transifex" stage which is kind of implied.

No, there's no fees or anything for Transifex... and yes, we've already got a test subject: Mer. (And if any other smaller projects out there wish to be a part of the testing and evaluation phase, by all means let us know.)

All of this is outlined in the Task page already... unless I completely misunderstood what Quim was saying.

Re: Community translations of Maemo software
 

Transifex itself (or whatever oss tool we choose) is free as in beer and freedom, but integrating it to Harmattan's localization process and maintaining it in maemo.org will cost some hours and euros.

It's a tool that will be used basically by the community. We don't mind whether the council has a say or not, but it makes sense that we seek the community endorsement before going for serious implementation.

If zerojay goes ahead with his push (thank you!) and comes up with a recommendation + the maemo.org webmaster agrees + glezos (or whoever lead developer of the localization tool chosen) also agrees, I think we are all set. :)

Re: Community translations of Maemo software
 

OK, cool. Sorry if I flew off the handle; but "let the council decide" sounded like a cop-out ;-)

Re: Community translations of Maemo software
 

Since the Summit is probably the best place where most groups involved can join in a BoF session (translators, developers, admins), I've submitted to lead such a session:

http://wiki.maemo.org/Maemo_Summit_2...y_translations

I think we should mention that Mer has already been testing Tx and providing valuable feedback. I'd love to start collecting more requests and see how they fit with the Transifex roadmap, what extra features we want to see implemented, and how we can best integrate the platform with all the workflows people follow.

Re: Community translations of Maemo software
 

Peer review is vital in localisation teams. This we improve or ack changes made by each other hence ensuring a certain community quality while providing more confidence for commercial value (e.g. Nokia).

Looking forward contributing to Dutch translations. :)

Re: Community translations of Maemo software
 

glezos, we'll talk soon and hopefully also at Maemo Summit. I really want to push this into reality.

Re: Community translations of Maemo software
 

Same here.
I'm looking forward to contributing (more) to french localisation.

One thing to note.
Whatever the tools choosen, don't forbid the use of text files as a medium of localisation.
I know some people wich are really more confortable with a text file containing the strings to translate than a web tool.

Re: Community translations of Maemo software
 

Then you run into different problems such as encoding issues. Much better to let the web tool handle that for us.

Re: Community translations of Maemo software
 

Mmmh, not if you use a descent editor.

All the firefox et al (including fennec) localisation directly with a text editor without any problem.

Dealing with text files have some avantages (like offline editing, quick fix, grep, export to other formats...)

Re: Community translations of Maemo software
 

I've got too much professional experience in dealing with translators and localization to jump onboard with that. It's been a disaster each and every time.

I suppose there's nothing stopping you from just editing and committing to SVN yourself and just avoiding any web-based solution if you really wanted to.

Re: Community translations of Maemo software
 

I understand your point of view. From a professionnal approach, if you are dealing with professionnal translator without large technical skills.

But here we are dealing with technical persons (with good language skills) who want to translate.


No, I don't think so.

I am not really used to web based tool, but from what I've tested, I'm really faster with a file and cvs and co. (If the file format is good).