- OpenStack-I18n - lists.openstack.org

What's up and what's next? I18n team
by Ying Chun Guo 17 Nov '13

17 Nov '13

Hi, all The openstack summit was held last week. There were 4 sessions in total related with OpenStack I18n. I had chances to discuss with Doc team, Oslo team, Infra team and release management team about I18n tools and processes. I got very positive results. It turns out that leaders in OpenStack community think I18n as a very important area ( which is great ). I summarize what happened in the summit here. 1. Publishing translated documentation (https://etherpad.openstack.org/p/icehouse-doc-translation) The translated document publish process was discussed in this session. The decision was to have two servers to publish translated documents: official server and staging server. The official server will be used to publish the well translated documents. Staging server will be used to host the ongoing translated documents, which will help the review process. 2. Translation tools and scripts (https://etherpad.openstack.org/p/icehouse-summit-translation-tools-and-scri…) This discussion was held to decide whether we went away from Transifex (because of some well known reasons, if you don't know, please contact me) and moved to another translation platform. After comparing with several famous translation platforms, we figured out Transifex was the best one till now. As Transifex won't trun off in a short time, we will continue to use Transifex. At the same time, we will contact Transifex as well as other translation tool communities, to raise the feature requirements and see how they can satisfy us. Then we make decision in several months. 3. I18n policies of messages (https://etherpad.openstack.org/p/icehouse-oslo-i18n-policies) This session was to discuss the messages translation policies. The result was to separate messages ( log messages, API response messages, and etc ) into different po files, and let translation teams/coordinators to decide the translation priorities. Another result was to introduce message IDs to log messages, which will enable searching and bug diagnosis if log messages are not in English. (It's a great change from the software architecture view.) 4. Icehouse release schedule & coordination I had chance to explain our translation process with "big guys" in Openstack community. This session is more related with messages translation than documents translation. In a release cycle, message translations will be continuously imported into git repository. At last, the translation teams can decide which languages should be shipped with release. (None translation team supported languages will be removed.) Havana was called a conclusion, and Icehouse was just kicked off. We shall also make our plans in this release cycle. I have the following items in my mind: 1. Publish Japanese operation guide in the website. Operation guide in other languages are welcomed too. For translation teams, if you have plans to translate, please let me know. We can figure out a reasonable plan for the translation work. 2. Re-organize the I18n wiki page. Clearly list our team structure. I plan to use "I18n team" and "L10n teams" to manage. I18n team will be responsible for OpenStack I18n, which means to help OpenStack to become a software that can be localized. I18n includes setting up translation process, changing code infrastructure, and so on. L10n teams will be responsible for OpenStack L10n, including translation and localization. People can join both I18n team and his/her L10n team. People can join only 1 team also. The wiki page shall list clearly these information. Here are good samples: https://l10n.gnome.org/teams/ and http://loco.ubuntu.com/teams/. 3. Use Launchpad to manage bugs and blueprints. Find a way to track the contributors. If we are not able to track them automatically, let's track them manually. Coordinators please help to track the contributors to your language translations. At least, remember and display their names. 4. Enable translation function in MediaWiki If we want to translate wiki page, we will use the translation function in MediaWiki itself to manage. 5. Separate log messages into different po files & enable messages IDs This work may need more developers to join. 6. Contact with Transifex, Pootle, Zanata, TranslationWiki to raise feature requirements. 7. Set up staging server for translated document review. 8. Continue translations in documents and messages. Surely I'm not able to do all these works myself and I need all kinds of help. If you are suggests/comments to these items, please speak out. If you are interested in some, please sign up. Let's start the discussion in the mailing list. We missed 1 IRC meeting because of the summit. We will have next IRC meeting next week on Nov 21th. At that time, hope we can have a clear plan at that time. Regards Ying Chun Guo (Daisy)

5 5

Horizon(Havana) found typing error at korean translation.
by Sungjin Kang 17 Nov '13

17 Nov '13

Hi, Sorry, Horizon korean translation is typing error. Firewall page -> Policy is “폴린드어(Polish)”…. :( So, I edited Transifex this string. :) This edit patch at next horizon update(2013.2.1). PLZ…. And where is typing error reporting? Launchpad?? or other?? Thanks, Sungjin

3 2

Collecting requirements to translation tools
by Ying Chun Guo 17 Nov '13

17 Nov '13

Hi, I18n team One year ago, when the community was making the decision to use Transifex as the translation management tool, a table was made to compare several different tools: https://docs.google.com/spreadsheet/ccc?key=0Aqevw3Q-ErDUdFgzT3VNVXQxd095bF… Now since Transifex began to close its source code, we will do another round of tool selection to find the translation management tool for Openstack translation. We will start from requirements collection. Here I listed some. (Some are copied from the old table. The last three items are newly added. ) * Cross-project translation teams * Cross-project translation memory * Good in-browser translation interface * Good in-browser review interface * Easy import/export of translation files * Support for all common translation formats * Git/GitHub Integration * Hooks for CI infrastructure * Management workflows that fit OpenStack process * Self-hosted * Proven success with large projects * API to gather statistics about translators * Easily see the translating context, i.g. the paragraph or section that contains the translation string. * Cross-project glossary and dictionary Please feel free to present your requirements to the translation management tool. If you know some good candidate tools, please speak out too. Let's find out the most appropriate tool together, and build a "wonderful" working environment for ourselves. Regards Ying Chun Guo (Daisy)

6 13

Interested in contributing translations for OpenStack
by Shilla Saebi 14 Nov '13

14 Nov '13

Hello, I signed up for an account in Transifex and attempted to add an available language (Persian - Farsi) but I was only able to request the language. Per the following link: https://wiki.openstack.org/wiki/Documentation/Translation I should see an option to create language but I did not see that. Can you please take a look and let me know what's going on? Thanks a lot! Shilla Saebi

3 2

Re: [Openstack-i18n] [Openstack-docs] On translations and ITS
by Tom Fifield 04 Nov '13

04 Nov '13

(CC OpenStack-i18n - consider joining!) A very nice lead in discussion to our two sessions related to this at the summit :) Right now, we have some custom code for 1 that has been customised for the OpenStack docs (for example, it excludes screen elements ;)), giving some of the practical benefits of ITS. It's in tools/generatepot. Looking forward to discussing more next week. Regards, Tom On 02/11/13 05:34, Shaun McCance wrote: > I have some experience (read: bias) in translation tools, so I'm writing > up a synopsis in the hopes in will be useful for the documentation > translation session at the summit next week. > > Document translation generally follows a three-step process: > > 1) Segmentation: A program takes the XML files and breaks it up into > chunks (often paragraphs) that can be individually translated and > tracked. These are usually stored in either PO or XLIFF files, but in > some systems they might be records in a database. > > 2) Translation: Translators translate those segments. They might edit > the PO or XLIFF files directly. They might use a graphical front-end. > They might do it through a web site that hides the files from them, but > still presents the individual segments. > > 3) Merging: A program takes the translated segments, matches them up to > the appropriate nodes in the source document, and writes a localized XML > file. > > Online tools like Transifex, Zanata, and Pootle are really about step 2, > but they often include code for steps 1 and 3 to give you an all-in-one > package. Unfortunately, to my knowledge, none of them use the W3C > Internationalization Tag Set (ITS) to accomplish those steps. Luckily, > they let you provide POT files and can give you PO files, which means > you can plug your own code in for steps 1 and 3. > > ITS is a W3C recommendation that provides a standard way to specify what > parts of a document are translatable, what elements are inline, and > various other things that are really critical for good segmentation. ITS > 2.0 was released this week, and addresses a whole slew of other issues. > > http://www.w3.org/TR/its20/ > > ITS lets you assert things about elements on a global level using XPath > expression. For example, let's say we don't want any of our screen > elements to be translated. We could use a rule like this: > > <its:translateRule translate="no" selector="//db:screen"/> > > Magically, hundreds of messages will disappear from translators' view, > allowing them time to have dinner with their families instead. You can > also mark things locally. So for example, if we don't want to exclude > all screen elements from translation, then on the ones we do want to > exclude, we'd write this: > > <screen its:translate="no"> > > You can also specify which elements are within text (inline), which are > space-preserving, where there are references to external resources like > images that have to be localized, and lots more. > > Biased opinion: If you have an XML translation process that doesn't > involve ITS, you're doing something wrong. (Disclosure: I was on the > working group that created ITS 2.0, and I'm the developer of itstool.) > > There are a number of tools that support ITS. Many of them work with PO > or XLIFF files, so you can plug them into most online translation tools. > I happen to be fond of my program, itstool, which supports PO files and > has a number of extensions that have been useful for other open source > projects like GNOME. > > http://itstool.org/ > > If you want a workflow that uses XLIFF files, you should look into > Okapi, a fantastic open source framework that supports ITS. > > http://okapi.sourceforge.net/ > > I do have a dog in this race, so I'm trying not to be too pushy. But > there are a lot of smart people who spent a lot of time figuring this > stuff out. If you have non-ITS segmentation and merging code, you'll > just end up chasing problems that have already been solved. > > If it's not obvious, I love talking about this stuff. So feel free to > ask me questions. > > Thanks, > Shaun > > > > _______________________________________________ > Openstack-docs mailing list > Openstack-docs(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs >

3 3

experiences and tips in ops-guide translation (a case of Japanese community)
by Akihiro Motoki 03 Nov '13

03 Nov '13

Hi I18N community, I summarized our experiences and tips of Japanese community in ops-guide translation. https://docs.google.com/presentation/d/1kQN-9765PzNbTSw5YoSl9kNOsUU_Gj74HQZ… While several months passed after the ops-guide translation finished, I believe it is still useful to clarify requirements for document translations and it may bring us some ideas in the discussion in Hong Kong and the future. I don't think our approach works well for everyone and is ideal, but at least it works for us and makes us much efficient compared to a case where we use Transifex. Thanks, Akihiro

3 3

Relevant sessions for i18n at the summit
by Tom Fifield 02 Nov '13

02 Nov '13

Hi, A couple of people have asked about sessions they can attend about i18n at the summit. Here's my list: Thursday November 7, 2013 11:00am - 11:40am AWE Level 2, Room 202 Translation tools and scripts http://icehousedesignsummit.sched.org/event/36d10d27f8a030c02fc35553cc24187… Tuesday, November 5 • 3:40pm - 4:20pm AWE Level 2, Room 202 Publishing translated documentation http://icehousedesignsummit.sched.org/event/a7731c633cd4c57d4647af8c5482941… Wednesday November 6, 2013 11:15am - 11:55am AWE Level 2, Room 201B I18n policies of messages http://icehousedesignsummit.sched.org/event/b55de8b048803806c9acace66c21f6d… Friday, November 8 • 5:00pm - 5:40pm Developing a Roadmap for Global Adoption: Exploring OpenStack's Globalization Best Practices http://openstacksummitnovember2013.sched.org/event/70cbdbcb75e4b20410d318e1… Friday November 8, 2013 4:10pm - 4:50pm AWE Level 2, Room 204-205 Icehouse release schedule & coordination http://icehousedesignsummit.sched.org/event/839c04a94f50b18f3b963d8e1c58707… Regards, Tom

1 0

Collecting requirements to translation tools
by Dwayne Bailey 30 Oct '13

30 Oct '13

Hi There, I was pointed to this discussion while on #pootle. Let me give some feedback on the items listed on your Google Doc adding info as needed and correcting any errors that I see. - *Cross-project translation teams* - Not 100% sure of the exact needs here. Pootle has a user centric permissions model, users can have permissions for languages, projects and translation project (i.e. a project in a given language). - *Cross-project translation memory* - Yes served from Amagama our global TM server. Amagama is a publicly hosted server loaded with translations for FOSS projects, optimised for high speed Levenshtein distance measurement. - We're landing local TM in Pootle in the next few weeks. - *Strong Crowdsource community* - Does this mean the development team or the translators on a shared hosted platform, seems to indicate the later based on the current analysis. - Simple management interface for project resources - Would someone mind elaborating on what the main benefits or use case for resources are for openstack? - Good in-browser management of resource priorities - Would someone mind elaborating on what the main benefits or use case for resources are for openstack? - While we don't have resource priorities Pootle does allow you to place files into goals. These goals can be prioritised to ensure that translators focus on the most important aspects of translation first. - *Proven success with large projects* - LibreOffice, Apache OpenOffice, Mozilla - Firefox, Thunderbird, Firefox OS and website localisations, Evernote. - *API to gather statistics about translators* - Data is there, the API framework is in place but no active users so no finalised, published or stable API - *Easily see the translating context, i.g. the paragraph or section that contains the translation string.* - Yes. Have a look at http://mozilla.locamotion.org/bn_IN/firefox/translate/#filter=incomplete&un… - Surrounding translations even when moving through the editors in a filtered way. You can expand and contract this context as needed and it is hidden when stepping through all translations to remove clutter. - You will see location information e.g. file location as well as line number if that is the only context you have - msgctxt and notes are shown if present. We don't show anything that doesn't exists, which might explain the current comment on the spreadsheet. Pootle UI approach is that we only show what is available i.e. no comment then we won't show you a missing comment. - *Cross-project glossary and dictionary* - Yes. Cross-project, you can load any terminology resource into any language's Terminology project - A project specific terminology file can also be used. - We don't have any specific dictionary integration but use Weblookups for e.g. Wikipedia to make it easy to research source texts without leaving Pootle UI. - *Code maturity (age of the code)* - Pootle was officially released in Dec 2004, about the same time as Launchpad, http://translate.sourceforge.net/pootle-release-2004-12-16.html - So almost 9 years of history in Pootle. The Translate Toolkit is somewhat older. Virtaal, our desktop translation tool, is younger. - Query by filename (eg to assign particular xml files for translation within a resource, as in Japanese ops guide translation) - Does that mean you have a repo but only want to see certain files? - Pootle can ignore files, so the opposite of that - Merging of uploaded PO files, so that only translations that changed in the PO file are changed in the project. Avoids overwriting when multiple translators work offline. - Yes, when uploading you have 3 choices, overwrite (if you have permission), turn conflicts into suggestion or make everything a suggestion - We err on making things a suggestion if we can't resolve the change. So does mean you might need to review the suggestions for your translations. - Performance of translation memory matching for non-latin languages - We use Levenshtein matching. So we're not doing anything special for non-Latin languages. - Training available? (devs, users, none) - Not sure what the needs or wants are here exactly - We've trained localisers across Africa, in India and other places - Written localisation guides for FOSS - Run Translateathons - etc - Roadmap - We haven't published a public roadmap but will be doing that once we get 2.5.1 out the door. Scheduled to go into beta this week. - Technical Support - Translate provides commercial support and development, primarily development - There is an active community that assist on the mailing list and IRC channels. -- Dwayne *Translate* +27 12 460 1095 (work)

1 0

Release Notes pt_BR
by Gabriel Wainer 29 Oct '13

29 Oct '13

Hi all, Finally, the pt_BR release notes are done. I've also added the link in the original page. https://wiki.openstack.org/wiki/ReleaseNotes/Havana/pt_BR Thanks! Gabriel.

2 1

Translated documents publish processing discussion in HongKong summit
by Ying Chun Guo 28 Oct '13

28 Oct '13

Hi, In HongKong summit, there is a slot in doc track to discuss about publish process of translated documents. If you will attend the design summit, I hope you can join the discussion and share your points with us. Hope to see you there. Regards Ying Chun Guo (Daisy) ----- Forwarded by Ying Chun Guo/China/IBM on 2013/10/24 09:09 ----- Anne Gentle <anne(a)openstack.org> wrote on 2013/10/23 11:09:01: > Anne Gentle <anne(a)openstack.org> > 2013/10/23 11:09 > > To > > "openstack-docs(a)lists.openstack.org" <openstack-docs(a)lists.openstack.org>, > > cc > > Subject > > [Openstack-docs] Summit Doc track proposals due > > Hi all, > We have four proposals for four slots for the Summit, I'm happy to > combine or re-think the spots if someone else wants to hold a > discussion in Hong Kong. > > Application Developer Resources Everett Toews > Automated Doc Tooling - status & plans Tom Fifield > Status and future of the restructure Tom Fifield > Publishing translated documentation Anne Gentle > I'm trying to get Todd Morey to do a short show-n-tell of a new > design for the docs site at the Summit, will keep you all posted. > > I don't see any specific API talks here, guess we'll look for those > in the nova v3 sessions. > > I'm also working on hosting a post-Summit "live" review event online > where we go over what the plans are for Icehouse. > > Thanks, > Anne_______________________________________________ > Openstack-docs mailing list > Openstack-docs(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs

2 1