Open Stack

Thank you for the patch, Akihiro.
I think it's easier to discuss in email.
So I copied your comments in your patch here.

> Expected workflow:
> * add an entry to the master glossary:
> - Update glossary/master.yaml and review it on gerrit
> - Once approved, glossary-tool sync will update per-language glossary
files and propose the update to gerrit (jenkins jos)

In your design, when the changes to master.yaml is approved, how to trigger
the jenkins job ? using a tag ?
I think we could add one more action in this Jenkins job: automatically
send an email to i18n to notify that the glossary is changed.

> * update per-language glossary:
> - Each language team upload a proposed glossary to gerrit. A language
team members review it and once they have a consensus i18n core reviewer
merges it into the repository.
> - Once approved, a corresponding glossary PO file is generated and
uploaded to Zanata. (glossary-tool write-po and jenkins job)

In your design, translators will not use translation editor in Zanata to
translate glossary.
Translators will propose the glossary translation to gerrit.
I don't know if translators have enough training to commit a patch.
They may understand how to use Zanata more than how to use gerrit.
There is no commands to support uploading glossary to Zanata.
So the action to upload po files have to be executed manually.

How do you think if we change to:
- Update glossary/master.yaml and review it on gerrit.
- Once approved, glossary-tool sync will update per-language glossary files
and propose the update to gerrit (jenkins jos).
- The jenkins job will upload pot file in Zanata.
- The jenkins job will send email to i18n to notify the change.
- Translators log in to Zanata to translate.
- Jenkins job download po files to i18n repository.
- Zanata admin automatic update Zanata glossary.

> * syntax when a review is proposed
>- 'glossary-tool' check verifies if YAML data is valid. It can be a part
of pep8 target.

Good to have syntax check.

BTW, how do you think the advantage of YAML file, comparing with po and pot
files?
Because if we use po and pot files directly, we could put "note" as
comments in pot files.
Do you want "note" also be translated ?

Regards
Daisy


Akihiro Motoki <amotoki at gmail.com> wrote on 2016/01/05 07:05:51:

> From: Akihiro Motoki <amotoki at gmail.com>
> To: Ying Chun Guo/China/IBM at IBMCN
> Cc: "openstack-i18n at lists.openstack.org"
<Openstack-i18n at lists.openstack.org>
> Date: 2016/01/05 07:07
> Subject: Re: [Openstack-i18n] How do we manage glossary?
>
> Hi Daisy and the team,
>
> 2015-12-17 19:35 GMT+09:00 Ying Chun Guo <guoyingc at cn.ibm.com>:
> > Hi, Akihiro
> >
> > Please let me know your comments to https://review.openstack.org/258924
>
> I commented your above review.
>
> I proposed a counter proposal https://review.openstack.org/261767.
> This is just an idea. I am open to the input.
>
> Comments inline below.
>
> > Answers to your question:
> >
> > 1. Context
> >
> > The current solution in my patch could not satisfy this requirement
about
> > context.
> > If we want to put context to glossary, we need to develop our own
extension
> > of sphinx-build.
> > How do you think the priority to support context ?
>
> IMHO supporting contexts is important to make discussion on glossary
> productive.
> As you can see in Japanese glossary on OpenStack wiki [1], I believe
> that discussion contexts
> are important for further discussions and it also helps new
> contributors understand the background.
>
> In my proposal https://review.openstack.org/261767,
> we maintain all contexts in YAML glossary files.
>
> > 2. Process
> >
> > If people want to change the glossary, e.g. add, update, change the
> > comments, add coments
> > following process is designed.
> >
> > a> the requestor submits a patch to i18n repo
> > b> core team approve the patch
> > c> the auto uploading process is triggered. terminology.pot is uploaded
to
> > Zanata for translation
> > d> translators finish translation
> > e> Zanata admin manually patch terminology.pot and its translationpo
files,
> > and upload to Zanata
>
> IMO the glossary needs to be reviewed more carefully compared to
> regular translations.
> In regular translations, all translated strings are imported, but for
> glossary it is better that
> only reviewed strings are imported. Another choice is to use gerrit
> for the glossary review.
> My proposal https://review.openstack.org/261767 implements the latter
option.
>
> Thought?
>
> Thanks,
> Akihiro
>
> >
> > Best regards
> > Ying Chun Guo (Daisy)
> >
> >
> > Akihiro Motoki <amotoki at gmail.com> wrote on 2015/12/02 02:29:44:
> >
> >> From: Akihiro Motoki <amotoki at gmail.com>
> >> To: "openstack-i18n at lists.openstack.org"
> >> <Openstack-i18n at lists.openstack.org>
> >> Date: 2015/12/02 02:32
> >> Subject: [Openstack-i18n] How do we manage glossary?
> >
> >>
> >> Hi team,
> >>
> >> Recently we added the glossary to the i18n repo [1].
> >> I wonder how we can manage the glossary and am sending this mail.
> >> The glossary can be referred to in Zanata, so it would be useful.
> >>
> >> Mainly I have two questions.
> >>
> >> The first point is what is the expected process to manage the
glossary.
> >> How can we update the glossary?
> >> When is it uploaded to Zanata for translations?
> >>
> >> The second point is how we can have the context.
> >> I think the second point is also important.
> >> Each entry in our glossary has some background, for example
> >> why we reach the current consensus.
> >> This kind of context is important to discuss for further improvements.
> >>
> >> I updated the glossary for Japanese translation last week
> >> and I added various description about backgrounds of the glossary.
> >> I feel it is important to keep the context.
> >> How can we manage the context?
> >>
> >> I don't have a good idea now.
> >> I would like to raise these questions for broader discussion.
> >>
> >> Thanks,
> >> Akihiro
> >>
> >> [1] http://git.openstack.org/cgit/openstack/i18n/tree/i18n
> >>
> >> _______________________________________________
> >> Openstack-i18n mailing list
> >> Openstack-i18n at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-i18n/attachments/20160105/db9f32a7/attachment.html>