[Openstack-i18n] How do we manage glossary?
amotoki at gmail.com
Mon Jan 11 16:06:33 UTC 2016
Thanks Alex for very helpful comments.
2016-01-06 8:02 GMT+09:00 Alex Eng <aeng at redhat.com>:
>> However, my question is still how to keep discussion contexts (or
>> It seems Zanata history is associated with Zanata internal resource ID.
>> I am afraid it can be easily lost and we cannot recover it :-(
> Yes, Zanata associate our internal resource ID to history.
> But I don't understand why is that an issue given all translators are
> already registered in Zanata and have their user id. (correct me if I'm
> wrong about what you mean Akihiro)
> I don't think the data can be easily lost as everything is in database. I'm
> sure infrastructure team have prepared for backup and even restore if
> anything happens.
> Keep in mind if there's possibility of data lost, that would mean same for
> all translations history.
Sorry that My previous comment was confusing. Let me follow them up.
I agree that the data will be easily lost. It is correct.
My point is "Can we see histories for a removed glossary entry?"
This affects various points.
We sometimes drops an entry, renames an entry, or once drops and then
restores an entry.
If we drops some entry, in my understanding, we cannot refer to it
This is the reason that I said we easily lost histories. At least git
allows us to do it.
The reason I am emphasizing "context" (i.e. discussion history) of
each glossary entry
is that we cannot assign a single word to an entry and we need to
choose an appropriate word
depending on a context. Without such information, we cannot choose
> Another benefit I can see is that their contributions will be included in
> their statistics.
>> Japanese team actually maintains it in OpenStack wiki and it works mostly
>> except that we need to sync glossary manually, but it might be a small
>> compared to keep "context". Keeping "context" will save time to explain
>> we choose THIS in our current glossary. If we do not have it, we need to
>> explain same things to new contributors again and again, and this will
>> the barrier to new contributors.
> This is one of the improvement we want to make as Glossary in Zanata at the
> moment is global (everyone shares the same glossary).
> We might look into levelling Glossary into project level or even concept of
> context glossary where you can select which group glossary you wish to use.
> Please feel free to provide us feedback if such feature is needed.
I am sure we need glossary at project level or group level at the moment.
I don't think each language team has enough human resources to maintain
glossary at project level.
Can each language team maintain a glossary in Zanata without having
I think we should first explore how we can leverage the current
glossary feature in Zanata.
We can open "Glossary Detail" panel from the usual translation panel.
I wonder how each language team can use a glossary.
At now, only admin can manage a glossary of each language, but 'admin'
does not know
the detail of each language. I think this is the main pain point, and
we are discussing
how to manage glossary.
# I might be missing something. If so, let me show a pointer.
# I believe I am a heavy user of OpenStack Zanata but I am not aware of it.
> Another thing you might want to explore is to use our translation memory
> import export. It has the concept of group (context) and it shows up in
> translation memory panel.
> But only limitation is that it only supports .tmx file. You can access it
> through "admin" screen and "translation memory"
I am not sure how the proposal above helps us.
> Alex Eng
> Globalisation Tools Engineering
> DID: +61 3514 8262
> Mobile: +614 2335 3457
> Red Hat, Asia-Pacific Pty Ltd
> Level 1, 193 North Quay
> Brisbane 4000
> Office: +61 7 3514 8100
> Fax: +61 7 3514 8199
> Website: www.redhat.com
More information about the Openstack-i18n