- OpenStack-I18n - lists.openstack.org

Havana - Horizon translations update
by Julie Pichon 25 Nov '13

25 Nov '13

Hi all, I was reading Daisy's summary of the Summit's i18n events - lots of great stuff happening, that is awesome! :) I would like to clarify the current status of the Transifex repository, and next translation update. I think it would be awesome to get another translation update in 2013.2.1 (first Havana stable update, planned in early December [0]), to include improved translations and maybe even new languages who may have missed the first deadline. My understanding was that we stopped updating the strings in Transifex from master around Havana RC3, to avoid the Icehouse strings sneaking in. Is this correct? Are we still tracking the Havana strings in Transifex? Kind regards, Julie [0] https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fhavana…

5 10

Translation check site (automatic Tx import is now resumed)
by Akihiro Motoki 24 Nov '13

24 Nov '13

Hi all, As we discussed in the last IRC meeting, I just resumed automatic translation import on the translation check site I am running. http://v157-7-133-23.myvps.jp:13580/ Username : demo / admin Password : opstjpHavana devstack with stable/havana release (today's latest) is running on the site. Translations are imported automatically from Transifex every hour. The list of available languages contains not only languages with Havana release but also languages with some translations on Transifex. If you don't see your language on the list, please let me know. Thanks, Akihiro

1 0

Results of the meeting with Transifex
by Stefano Maffulli 23 Nov '13

23 Nov '13

hello all, I met with Transifex CEO yesterday as a follow up to the i18n tools and processes session in Hong Kong. As we agreed, I let them know that we're not happy with their decision to stop developing the Open Source version of Transifex and that because of that we've decided to look into alternatives for the medium term. For the short term we're still going to use Transifex, therefore the meeting was to understand how we can get some features we need. Below are some notes from the meeting. I have put Daisy in touch with Dimitris so they can talk directly from now on. I'm waiting for Dimitris to send us an estimate of the costs for the enterprise features that the i18n team needs. We'll keep the conversation going once we get that proposal. Cheers, Stef Notes ----- - Openstack interested in Sharing Teams and Reports/Analytics on translations. - Transifex will have a member of its team to handle OpenStack questions. Questions from OpenStack team ----------------------------- - How are PO files merged when translated offline and online at the same time. Requested docs from Tx team. Dimitris notes that with time more and more translators will work online. - In-context for docs: Need a way to see the text with the images for QA. Transifex is working on new technologies which will fully support this. - Managing multiple versions of a product. Dimitris shared 3 ways, best one was: Have one Project on Tx which is rolling release. When a maintenance version needs to be released, create a separate project temporarily. If the two projects share teams, TM, Glossary and have "Auto-fill 100% matches from Translation Memory" it will work great. Drawing: https://www.dropbox.com/s/lyjulmut1qtr5n6/IMG_20131121_123037.JPG - Add support to login via OpenID: Doable. -- Ask and answer questions on https://ask.openstack.org

2 1

RFC: [Horizon translation] string "%(action)s %(data_type)s"
by Akihiro Motoki 20 Nov '13

20 Nov '13

Hi Horizon translators, I have a plan to make a small fix in Horizon strings in upstream code and if possible backport to Havana. Don't you have difficulties when translating a string "%(action)s %(data_type)s" in Horizon? It is used in two places: - to generate "action name" in the table (e.g. "Delete Network" in the pull-down menu and "Confirm Delete Network") - to generate "success message" (e.g. "Deleted Network: net2" in a success message pop-up) In Japanese we would like to use different translated strings for these strings (they are called "present" and "past" message respectively). Otherwise we can't get natural strings in translations. gettext has a mechanism called "message context", which allows us to translate a same string in different contexts. I have a plan to add a context to this string and allow us to use different translated words for the string. Once my fix is merged, we have the following entries in the PO file. The entries will become fuzzy, but we can reuse the existing translations so I believe the impact is small and we can get a benefit. Thought? Before proposing a patch, I would like to know feedbacks from I18N community. ---- #: tables/actions.py:562 #, python-format msgctxt "past" msgid "%(action)s %(data_type)s" msgstr "" #: tables/actions.py:564 #, python-format msgctxt "present" msgid "%(action)s %(data_type)s" msgstr "" --- Thanks, Akihiro Motoki <amotoki(a)gmail.com> / <motoki(a)da.jp.nec.com>

3 3

I18n team meeting tomorrow
by Ying Chun Guo 20 Nov '13

20 Nov '13

Hi, all There will be OpenStack I18n team meeting at 0000UTC on Thursday (Nov 21th) in IRC channel #openstack-meeting. The time, we use Asia/America friendly time. Welcome to join the meeting. This is the first I18n meeting after Icehouse design summit. Summarize of the design summit in I18n areas can be found here: http://lists.openstack.org/pipermail/openstack-i18n/2013-November/000294.ht…. This time, we will cover following topics this time: * Horizon translation update * I18n team structure discussion * Reorganize wiki page * Blueprints & bugs tracking * Plans in Icehouse cycle * Open discussion For more details, please look into https://wiki.openstack.org/wiki/Meetings/I18nTeamMeeting. You can also contact us through IRC channel #openstack-translation, or mailing address: openstack-i18n(a)list.openstack.org. Please refer to our wiki page for more details in the I18n area: https://wiki.openstack.org/wiki/I18nTeam Regards Ying Chun Guo (Daisy)

1 0

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

18 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 15 Nov '13

15 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 05 Nov '13

05 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