- OpenStack-I18n - lists.openstack.org

Translation warnings (Re: [OpenStack-docs] Code block in RST and translation)
by Akihiro Motoki 01 Dec '15

01 Dec '15

2015-11-25 23:54 GMT+09:00 Andreas Jaeger <aj(a)suse.com>: > On 2015-11-25 15:48, KATO Tomoyuki wrote: >>> >>> >>>> On 25 Nov 2015, at 03:41, KATO Tomoyuki <tomo(a)dream.daynight.jp> wrote: >>>> >>>>> My idea at now is to use "code-block" directive as possible as we can, >>>> >>>> >>>> As far as I know, docs team guides mainly use "code-block". >>>> So, I'm okay to unify to "code-block" directive. >>>> >>>>> but I am not sure it is the right direction as "::" is widely used. >>>> >>>> >>>> In my understand, most of developers like “::”, which is simple RST >>>> format :) >>> >>> >>> Maybe we could add a gate check that looks for “::” in the end of the >>> strings (original and translated)? It would enable developers to use >>> whatever they are used to. >> >> >> Nice idea! Sounds good to me, as a non-vote job. >> >> Regards, >> KATO Tomoyuki > > > But who will monitor this and correct it? > > We already see warnings in translated code that everybody ignores, let's > find a good way to monitor and fix these problems first before we add > more tests... I think this kind tests are categorized into two: (a) to detect anti-patterns which are not good for translations. (b) to detect warnings when building translation documents. I have no good idea on who monitors it. (b) can be a periodic job and language translators need to check them. Related to (b) warnings in translation documents, I cleaned up warnings in Japanese translations last night. At now, Japanese documents have no warnings except https://bugs.launchpad.net/openstack-manuals/+bug/1521473. Most of them can be fixed by - adding an extra white space after closing RST markups such as `` or **, or - removing extra white spaces at beginning or end of strings wrapped by RST markups. Even with these warnings, translated documents are rendered properly. On the other hand, some warnings are actually due to translation mistakes to be fixed. This turns out that checking warnings is still important. Akihiro > > Andreas > -- > Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter: jaegerandi > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton, > HRB 21284 (AG Nürnberg) > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 > > > > _______________________________________________ > Openstack-i18n mailing list > Openstack-i18n(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n

2 1

Upstream Training material publication
by KATO Tomoyuki 01 Dec '15

01 Dec '15

Hi team, Happily, we have new translation feature for Upstream Training material. Also, translation publication job is enabled at now. For ONLY this guide, the translated guide is published immediately. Amazingly, Korean team has almost finished translation. Congrats! http://docs.openstack.org/ko_KR/upstream-training/ Regards, KATO Tomoyuki

2 1

external reference in RST and translation
by Akihiro Motoki 27 Nov '15

27 Nov '15

Hi, It is about RST formatting and translation, again. I had a trouble in translating the following type of external references. The following style is used especially when the same reference is used multiple times. In this case, translators MUST keep an original label, in this case 'User guide' in English even if there is more appropriate string in each language. If translators translate such strings, we will get a broken external link. I don't have a good solution on this other than keep original strings at now. Any suggestions? (http://docs.openstack.org/contributor-guide/rst-conv/refs.html#external-ref…) ---- Here is an external web link separated from its definition: This paragraph contains the link to `User guide`_. ... .. format the link definition at the end of the file as follows: .. _`User guide`: http://docs.openstack.org/user-guide/ ---- Thanks, Akihiro

1 0

Code block in RST and translation
by Akihiro Motoki 27 Nov '15

27 Nov '15

Hi, According to [1], we use two types of code blocks in RST documentations. The one is to end a line with "::" [2] and the other is to use 'code-block'. During translation, I noticed the first style can be a wrong formatting in translated documents (it will be considered as "block quote" as far as I tested). It is not easy that translators understand "::" at end of line has a special meaning. To keep the format, translators MUST keep "::" at the end of line, but ":" is rarely used in some languages and I think they will forget "::" easily. In addition, it is hard to detect this kind of things during translation reviews. Note that other RST conventions are easier to be recognized as special because they are very different from usual strings. On the other hand, ending a line with "::" is a standard ReST convention and it is widely used in writing documents in ReST format. My idea at now is to use "code-block" directive as possible as we can, but I am not sure it is the right direction as "::" is widely used. Thought? Thanks, Akihiro [1] http://docs.openstack.org/contributor-guide/rst-conv/source-code.html [2] http://docs.openstack.org/contributor-guide/rst-conv/source-code.html#stand… [3] http://docs.openstack.org/contributor-guide/index.html#search-in-this-guide

4 6

Arch Design Guide RST conversion finished
by KATO Tomoyuki 27 Nov '15

27 Nov '15

Hi team, Docs team finished Arch Design Guide RST conversion. At now, new RST translation resource is uploaded to Zanata. openstack-manuals / arch-design (same name) Best Regards, KATO Tomoyuki

1 0

release notes translation
by KATO Tomoyuki 26 Nov '15

26 Nov '15

Hi team, Maybe, as you know, we have the new release notes tool "reno". As far as I know, reno doesn't have translation feature. I'm not sure whether it is planned or not. So, we need to contact and maybe work with reno team. Anyone, interested in taking a lead? Here is a rough blueprint: https://blueprints.launchpad.net/openstack-i18n/+spec/release-notes-transla… Best Regards, KATO Tomoyuki

2 2

DocImpact Changes
by Lana Brindley 25 Nov '15

25 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everyone, The DocImpact flag was implemented back in Havana to make it easier for developers to notify the documentation team when a patch might cause a change in the docs. This has had an overwhelming response, resulting in a huge amount of technical debt for the docs team, so we've been working on a plan to change how DocImpact works. This way, instead of just creating a lot of noise, it will hopefully go back to being a useful tool. This is written in more detail in our spec[1], but this email attempts to hit the highlights for you. TL;DR: In the future, you will need to add a description whenever you add a DocImpact flag in your commit message. Right now, if you create a patch and include 'DocImpact' in the commit message, Infra raises a bug in either the openstack-manuals queue, or (for some projects) your own project queue. DocImpact is capable of handling a description field, but this is rarely used. Instead, docs writers are having to dig through your patch to determine what (if any) change is required. What we are now implementing has two main facets: * The DocImpact flag can only be used if it includes a description. A Jenkins job will test for this, and if you include DocImpact without a description, the job will fail. The description can be a short note about what needs changing in the docs, a link to a gist or etherpad with more information, or a note about the location of incorrect docs. There are specific examples in the spec[2]. * Only Nova, Swift, Glance, Keystone, and Cinder will have DocImpact bugs created in the openstack-manuals queue. All other projects will have DocImpact bugs raised in their own queue. This is handled in [3] and [4]. This will hopefully reduce the volume of DocImpact bugs being created in the openstack-manuals queue, and also improve the quality of the bugs that are created. I know there is a fair amount of confusion over DocImpact already, so I'm more than happy to field questions on this. Thanks, Lana 1: http://specs.openstack.org/openstack/docs-specs/specs/mitaka/review-docimpa… 2: http://specs.openstack.org/openstack/docs-specs/specs/mitaka/review-docimpa… 3: https://review.openstack.org/#/c/248515/ 4: https://review.openstack.org/#/c/248549/ - -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://lanabrindley.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWU5Q0AAoJELppzVb4+KUyYz4H/j+iAG5x2iRiNbJMBgxm5Qb5 tvxzlOePHZa6VQKj1gYrp8wnBFab0CsNDt/U03D8H9D6No2hqz5qvFgOuMDXIOkS DXG+2RDD8xKMRS42t70mNtJu2oPl+9BWIre+Qyvjd7heicGd+lN/mqAvmwVV3tKB fwJl3iLrlSpwwsyunzR3LxGxzVfHUroRdFv11iQGQZNJYbS9DfOLsz66e5JBTZPh ZoCK8VAlEionaL8ExppoMPQOwpU0oYMWSjM2HGxlc/RDrNEz7HWfXl36nxqfw/mO q8Op0p5cn5UW4fYv/9Ufbw6k0JRgwODCwzSEzJ73gmOJpBrcTEdZKocnGDSdtYA= =CCIn -----END PGP SIGNATURE-----

3 3

New guides published
by Andreas Jaeger 25 Nov '15

25 Nov '15

FYI, Japanese networking guide and Chinese (zh_CN) Install Guides have been added as drafts: http://docs.openstack.org/draft/draft-index.html Andreas -- Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

1 0

Virtual Machine Image Guide RST conversion finished
by KATO Tomoyuki 25 Nov '15

25 Nov '15

Hi team, Sorry for late announce. Virtual Machine Image Guide RST conversion has finished. You can look at new translation resource at Zanata: openstack-manuals/image-guide (same name) Unfortunatelly, we has droped the translations with XML markup, which is replaced with RST markup. However, we can easily translate them from Zanata translation memory. Tips: The strings ":guilabel:`xxxx`" is needed to keep this structure. :guilabel:`[yourlanguage]` This is a kind of RST markup. Best Regards, KATO Tomoyuki

1 0

translate.openstack.org upgraded to Zanata 3.7.3
by Elizabeth K. Joseph 20 Nov '15

20 Nov '15

Hi everyone, Thanks to work by Steve Kowalik and testing the upgrades on our translate-dev server, we have landed the upgrade of the production Zanata server from 3.7.1 to 3.7.3. This isn't a major upgrade, but if you're curious as to what has changed, release notes are as follows for the two versions we've upgraded through: 3.7.2: http://docs.zanata.org/en/latest/release-notes/#372 3.7.3: http://docs.zanata.org/en/latest/release-notes/#373 We'd like to involve Daisy and others as we do subsequent upgrades, particularly when we reach the major releases. Steve has written a script to query the API prior to upgrade and after the upgrade on the dev server so that we can be more confident that all of our scripts will continue to work in production, and I'll ask for volunteers from this team to look at translate-dev to confirm that the UI acts the way we expect it to after upgrading translate-dev and before upgrading the production translate server. I've logged in and walked through the UI post upgrade today, but please let us know if you have any trouble. -- Elizabeth Krumbach Joseph || Lyz || pleia2

3 3