# I changed the thread title to the appropriate one. 2016-03-01 17:23 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com>:

Thank you for the input, Akihiro and Kato.

I'm not strict in local communication method and IRC ID. If you have clearly documented them in your team wiki, that's fine.

As to the glossary, I still think git repository is better than wiki to store glossaries. Git repo has strict control, while wiki has no controls at all. Wiki is used for frequently update purpose. After it turns to mature, Git repo is good to store.

I agree that it is better to use gerrit to manage glossaries, but all of my efforts disappointed me and discourage me to do more efforts. I already tried to maintain our glossary with context in our git repository. It used YAML file and converts it to PO files. It allowed us to keep contextual information. You said it will be discussed in the IRC meetings, but I got no feedback. I felt it was simply ignored (or rejected). (I could not join IRC meetings. If joining meetings is a requirement, I have to go away.) I clearly define what is required, but I don't see any counter solution provided and it forces me to use useless format (i.e., PO files). I believe I already have made enough proposal, but all of the results disappoints me and discourage me to try more efforts because it tends to waste my time. Finally, I tried to use another way to manage the glossary, then I was complained that it is not a standard way...... As a result, I had no way to satisfy requirements. Managing the glossary in two places is completely less-productive, maintain the master glossary with context information and then copy it into i18n repo (with losing the contextual information).

And, using pot/po file can make all translation teams to easily follow the same glossary list.

Do you mean even if the data format does not satisfy our requirements we should use it? Unified tools or formats are also important, but tools/format which do not satisfy requirements are useless.

As to the glossary, I still think git repository is better than wiki to store glossaries. Git repo has strict control, while wiki has no controls at all. Wiki is used for frequently update purpose. After it turns to mature, Git repo is good to store.

Regarding wiki usage, I don't think each language team page is not frequently updated. Does this mean a language team page does not fit into Wiki? I am not sure why we need to apply strict policy only for glossary. If the problem is that a wiki allows everyone to edit contents (i.e. glossary in this case), it is a problem of communication in a local language team. Final question. Gerrit is an easy way for translators or translation reviewers? If a language coordinator is forced to proxy maintaining glossaries, Perhaps, I am expecting too much and I may be better to be a translator. Akihiro

I understand Japanese glossaries are out of date and your team don't like the current one in Zanata. If that's your team decision, I'm OK to delete it from Zanata.

Thoughts?

Best regards Ying Chun Guo (Daisy)

"Kato, Tomoyuki" <kato.tomoyuki@jp.fujitsu.com> wrote on 2016/02/27 17:08:46:

...

From: "Kato, Tomoyuki" <kato.tomoyuki@jp.fujitsu.com> To: "'Akihiro Motoki'" <amotoki@gmail.com>, Ying Chun Guo/China/IBM@IBMCN Cc: Openstack-i18n <openstack-i18n@lists.openstack.org> Date: 2016/02/27 17:40 Subject: RE: [Openstack-i18n] To language team coordinators: get ready for Mitaka translation

...

...

Thanks Daisy for initiating this.

2016-02-25 17:53 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com>:

...

Dear coordinators,

Mitaka translation will be started at the beginning of March, and probably ended in the week of March 28. We need to get ourselves ready for Mitaka translation from now on.

Because of the join of IBM professional translators, we will be able to cover more projects in our translation plan of this release. Generally, the jobs of existing community translators will not be affected, focus on Horizon, same as before. IBM translators will focus on "other" projects.

Before Mitaka translation starts, there are several things you can do:

1. Update glossary.

If you don't have glossary translations in i18n repo[1], or you want to update glossary translations, you can send a patch with your translations or your updates to i18n repo directly.

I would like to raise a question how the glossary work? Is it actually working?

As one of coordinators of Japanese team, the glossary list itself is out-of-date. In addition to update per-language glossary, can we update a list of glossary itself?

Beyond this, the current format of PO file for the glossary lacks an essential feature as I described before. There is no way to describe the context. I wonder how the glossary help translations without the contextual information. As a result, Japanese team is forced to describe contextual information in translated strings. This is the reason we preferred to Wiki style glossary.

From the above observation, does it sound a good option to clear the whole entry of Zanata glossary of a specific language?

+1 to clear, as long as Japanese, as of now.

...

...

2. Document your local team communication method in the team wiki page[2].

While Mitaka translation starts, it's good to open your local communication channel to all of your language translators. Good communication is quite important for people from different places to work well together.

I missed the previous team meeting (it is not special to me due to the meeting time). I would like to make some follow-up comments on a local communication.

I personally would like to continue to use Gitter (hosted by Github) as a communication channel in Japanese team. From my past experience, it has various good merits. I felt the first point is really useful in the crunch time of Liberty translation reviews.

* Pros: * it has a notification mechanism. Unread messages will be notified via email. * It can be used via browser (without any extra application) * Unlimited archive as long as gitter room is open to everyone * Cons * it is not provided by OpenStack infra

Kato-san and Japanese team members, feel free to comment it. Your feedbacks would be really appreciated.

I agree to using Gitter in Japanese team.

In my understand, using IRC channel for local team is not mandatory, just an option.

...

...

3. Join IRC channel[3] #openstack-i18n with your zanata ID

As a coordinator, you have the responsibility to coordinate your language translations. A good practise is to show up in IRC and have your people to get you easily when they have troubles.

"with Zanata ID"? It is just an option. It is not a requirement. It is not a surprising thing someone uses an IRC nickname different from Zanata ID.

I'm using different IDs :) And, I'm not always join IRC because of my business reason and equipments. To coordinate my local language team, I'd like to use Gitter and local mailing list.

Regards, KATO Tomoyuki

...

Note that it is important we need to know each other who you are but it is not a requirement to use Zanata ID as IRC nickname if you already use a different IRC nick.

...

If you have any questions, talk to me. My IRC ID is "Daisy" in the channel of #openstack-i18n.

I can help you too. My nick is 'amotoki'. I am usually online from 0200UTC to 1600UTC.

# It will be easier to find me compared to finding Daisy on IRC :) # Just joking.. never mind Daisy!

Akihiro

...

Thank you.

Best regards Ying Chun Guo (Daisy)

[1] http://git.openstack.org/cgit/openstack/i18n/tree/i18n/locale [2] https://wiki.openstack.org/wiki/I18nTeam/team [3] https://wiki.openstack.org/wiki/IRC