*Translation tools and scripts
*Session proposed by Ying Chun Guo
*Thursday November  7, 2013 11:00am - 11:40am
*Design Summit 1
*Infrastructure

Transifex is used to manage the translations, which  now changes to close its source code. This session will re-evalute the  available translation tools and have a discussion whether to turn to  other open source translation management tools.

This session  will also go through the scripts related with translation, the  additional requirements, and the improvement plans in Icehouse.

1. Translation tools discussion

Our goal: Set up a tranlation platform to support the translation of documents, messages, wiki, common text, and etc.

"No perfect tools"
"The translation platform may be an integrated and customized solution."

Tools candidates:
https://docs.google.com/spreadsheet/ccc?key=0Aqevw3Q-ErDUdFgzT3VNVXQxd095bFgzODRmajJDeVE&usp=drive_web#gid=0

Score cards:
https://docs.google.com/spreadsheet/ccc?key=0AjlcroGaTsVpdG85eWhqSVEwU19TNHFZQTJYTzZxR1E#gid=0
(Sorry) I can't add comments to the score card, but Zanata can show the translating context.  (Unfortunately,) you have to click the #row-id, to unfold the context info.
Also, the Zanata editor can query by filename.

Summary:
	* Transifex is the best and the most mature tool. The disadvantanges include
		* Not open source.  
		* The free service cannot support stastics.
		* Not support multiple people to work offline at the same time (but no tool supports this :)) [Zanata can merge multiple PO uploads; no locking required.]
	* Pootle is the second mature tool. The main disadvantanges include
		* Resource management is not possible
		* User management is not very good.
		* Most of our translators are suitable with Transifex.
		* Need to redesign the integration and the translation process.
		* There is no crowd source capability
	* The main disadvantages of Zanata include
		* Not that mature
		* Integration with gerrit is not good.
		* No users stastics data

None of the tools are good for the review process of entire documents. (i.e. not strings from the code). We should extend the docs-draft process so we can see partially tranlated documents, as discussed in https://etherpad.openstack.org/p/icehouse-doc-translation (thanks to Monty & Jim for the reminder!)

TranslateWiki are desperately trying to get in touch

Monty likes the words "we can extend it", especially if it's a team of "other" people who will do the work :)

So, there's problems with an immediate move ... tell the product folks to fix A,B,C ... then it becomes a conversation...


Aside: we need to get the workflows solid.


Discussion:
1. Do we need to move away from Transifex?

Proposal: don't panic. It's not going to turn off tomorrow. Instead, create a rich, reasoned plan that takes into account our needs.n

Perhaps:
	* work with a particular tool to get it up to scratch
	* throw down the gauntlet for all tools
	* communicate with Transifex to express our feelings


2. Which one is the choice?

Currently unclear, but send a call out to all projects evaluated to see what improvements can be made.

2. Plan & action items

Requirement 1: Wiki translation
Action: Enable Mediawiki translations. ( maybe only a few pages )

Requirement 2: Review documents from a whole view
Action: A staging server to display the translated documents continously and enable comments to the translated documents.

Requirement 3. Management of multiple versions of translation for a resource
Action: Can we leverage git/gerrit? 

Requirement 4: Track bugs while reviewing documents

Increase visibility of the L10n/i18n team landing page, show activities, priorities, possible things to do, etc

Talk to Transifex, let them know how we feel about their change of course