Thanks Alex for very helpful comments. 2016-01-06 8:02 GMT+09:00 Alex Eng <aeng@redhat.com>:
However, my question is still how to keep discussion contexts (or history/background). 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 through Zanata. 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 appropriate word.
Another benefit I can see is that their contributions will be included in their statistics.
Totally Agree.
Japanese team actually maintains it in OpenStack wiki and it works mostly well except that we need to sync glossary manually, but it might be a small thing compared to keep "context". Keeping "context" will save time to explain why 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 increase 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 'admin' privilege? 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. Thanks, Akihiro
---------------------------------------------
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