1080617 - Investigate simplification of l10n story

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Localization, defect)

Description

[Jannis Leidel [:jezdez]]

What problems would this solve?
===============================
Verbatim is he in-house tool for localiztion but is incredibly hard to maintain from the MDN developer side. E.g. it doesn't auto-push updates to the po files and requires SSH access to a server, SVN commit permissions and help from the verbatim maintainer.

Transifex is a 3rd party self-service tool that has been in use by a huge amount of Open Source projects, including Django as well as Firefox OS and Mozilla Foundation projects.

Who would use this?
===================
The translations as well as the developers of MDN would use it.

What would users see?
=====================
A new interface for translating the MDN UI. All translations would still be there, there would be a translation memory and there would be team management possible. 

What would users do? What would happen as a result?
===================================================
They would use a different tool to translate the MDN UI, MDN developers would use a different and able-to-be-automated workflow to update the base translation catalog. This would reduce the amount of work required to maintain the MDN UI translations to a minimum.

Is there anything else we should know?
======================================

Comment 1

[Jeff Beatty [:gueroJeff]]

Verbatim is only one in-house l10n tool for localization. I would also recommend looking at Pontoon, which would provide in-context, dynamic localization, something that Transifex cannot supply.

Additionally, Transifex is a closed project. While the translation memory would be useful within Transifex, should you want to use the TM database outside of Transifex, you won't be able to retrieve it without a paid subscription to the service.

Localization teams that have been using Transifex for Firefox OS have begun to migrate away from Transifex because of the closed environment, updates to the tool were unstable and caused misalignments within the TM database, as well as the feeling that they had no control or say over the tool's development of process.

Comment 2

[Justin Crawford [:hoosteeno] [:jcrawford]]

When we worked on the most recent Affiliates redesign, the localizers used Pontoon. Feedback I heard included...
* Localizers much preferred Pontoon
* Developers much preferred Pontoon

On the developer side, :osmose is the right person to chat with.

Comment 3

[Jannis Leidel [:jezdez]]

:gueroJeff Thanks for your input, I agree there are many disadvantages to using a 3rd party tool like Transifex. I don't think paying a 3rd party for a service like the translation memory is a trade-off though, considering the level of maintenance required with the current system. I don't know how much work it'd be from the developers side with Pontoon. need-info'ing :osmose..

One correction to your statement though, Transifex does support Pontoon style localization nowadays with its new subproduct "Transifex Live": https://www.transifex.com/live/

I'll look into Pontoon more, but so far the Django integration didn't win me over from a technical perspective: https://github.com/rtnpro/django-pontoon-hook/

To clarify that I'm not without experience in this field, I've maintained the Django translations for a few years via Transifex.

Comment 4

[Jannis Leidel [:jezdez]]

I've updated the task to not only center around Transifex

Comment 5

[Osmose [:osmose, :mkelly]]

So my experience with pontoon was using it via SVN in the same way we used Verbatim. From my perspective the only difference was that I didn't have to ask before committing changes to SVN (since Pontoon auto-updates instead of Verbatim's manual updates) and if I wanted to see the status of translations the UI of pontoon was nicer. I also had to add a JS file to the dev environment for Pontoon to work.

The issues around needing SVN access, no auto-update, etc. still applied. I understand from a translator's point of view it was significantly better. And I needed to notify an l10n-driver about my changes even after merging so that they could notify localizers of new strings.

I can't speak to how things would change if you used some other method of getting the translations from Pontoon. Maybe it'd be better?

Comment 6

[[github robot]]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/f6cbe0a626ff8b67d62952032cb23f32a0c232f0
bug 1080617 - update l10n docs re: verbatim perms

https://github.com/mozilla/kuma/commit/e35f6bd2d24e2045e0809b278a89fb9a2a28d185
Merge pull request #2823 from groovecoder/update-l10n-docs-1080617

bug 1080617 - update l10n docs re: verbatim perms

Comment 7

[[github robot]]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/6c9cb62d91e191abaa7929c448a16595078173e2
bug 1080617 - update Matjaz email address

https://github.com/mozilla/kuma/commit/5690ca6ae7aebc55d3c403a209f8aabc100a1b23
Merge pull request #2827 from groovecoder/update-l10n-docs-1080617

bug 1080617 - update Matjaz email address

Comment 8

[Florian Scholz (Open Web Docs)]

:jezdez, we are on Pontoon now, can we close this?

Comment 9

[Jannis Leidel [:jezdez]]

Yep!