User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 Build Identifier: The translate.zanata.org instance has glossaries for some languages, and not for others. Glossary management should be done by the language coordinator, who would need to be able to create and manage a glossary. Glossary management ------------------- One should be able to: - (all) add source language terms with its source language information (en usually), and an optional context - (all) add an additional context for an existing entry, with or without proposed translation - (all) add possible translations for a particular context - (reviewers/maintainers) review the proposed translations, and allow its usage (all) refer to all possible roles within zanata: translators, reviewers, coordinators. Reproducible: Always
Thinking about it, how should be managed glossaries: - globally for the source words? - or tied to a particular target language? I guess it would make sense to have source words without context global (enabling sharing source entry glossaries with a general translation amongst all languages, which would help kickstart a glossary effort in a particular language: see all the terms spotted by other languages), and additional particular contexts local to a language. Thoughts?
And since we use multiple instances, we need to be able to share a glossary between multiple Zanata instances (read: bidirectional sync, to be linked with the acceptance workflow).
I do think sharing of glossary between instances is a good idea. We are currently looking at sharing Translation memory as the first steps for cross instance collaboration as it is more widely used by translators.
Hi Jerome, Glossary management is becoming one of the high priority that we would like to work on next few months. We will investigate the ways we can implement the better glossary management system and get back to you for your feedback later. Making this issue high priority to discuss. Thanks, Michelle
Hi Michelle, That's good news to read! Let me know if you want to setup an IRC or phone call session to discuss that further, I'm sure I can find some time to discuss this. Involving Red Hat's translators in Brisbane could also be an idea (Noriko-san, Sam Friedman, Corina Roe, Julie Carbone are the one I know of).
Hi Jerome, Great to hear. I will start talking with some of the translators to see how the glossary is developed here and schedule a meeting with you to discuss. Please stay tuned. Michelle
Hi, Just let me mention how current feature works well for Fedora community already, where current Zanata feature of glossary makes 'admin' to assign 'glossarist'. We can start from here. For fedora.zanata.org instance; 1. noriko and piotr as admin create a glossary. This glossary contains all languages. So that each team coordinator does not need to create one for each language. 2. noriko and piotr as admin assign 'glossarist' role to all language team coordinators (or any nominated by the team). This allows all language team coordinators (or nominated user) to add/edit the glossary, as well to share the source entries. 3. all users can use/view the glossary appeared in Zanata editor. Questions: do we (as Fedora community) really need to allow **every** translators to edit the glossary? About your comment2, "we need to be able to share a glossary between multiple Zanata instances"; If we have one glossary to be used for all zanata instances (community instances and internal instances) it might need so many glossarists to be added who have different perspectives for different products/projects. I rather see simpler having a glossary per instance, and then possibly having separate global glossary which is aggregation of available glossaries. This global glossary can be set read-only, allowing users to search and view? just my 2cents noriko
Hi Noriko, 1. Great, looking forward to see the glossary on fedora.zanata.org! 2. fine by me, 3. fine by me. Re my comment: we need to discuss separately the technical issue from the functional issue : - I'd like to avoid having multiple glossaries with diverging terms - Hence the proposal to have only one authoritative glossary which is replicated to other instances, maybe with a workflow for non-glossarists to add/request new terms and translations for their own languages. - Having a glossary per instance does not need anything new in Zanata, but will introduce confusion over time. Wild idea: maybe we need a glossary application that all zanata instances will use?
Hi Jerome, We had Glossary meeting to discuss your RFE and Zanata dev team has came up with new Glossary workflow proposal. I requested Zanata team to draw up an easy to understand diagram to share with you and others to get final agreement before we go ahead and talk about implementation details. The new diagram will be able to explain the global and project based glossary with permission who can create/edit the glossaries. One of the strong request we got from translators in regards to glossary was to be able to have multiple translations for one English depending on context as well as being able to sort the glossary results according to products. Until we have new glossary feature implemented, you can start using Glossary on translate.zanata.org as a glossarist. We can assign you the glossarist role if you are interested. Please let us know. Thanks, Michelle
Hi Alex, Can you please work with Luke to provide the new diagram of new glossary workflow proposal via this bugzilla to share with Jerome / Noriko and others? Thanks Michelle
Created attachment 1052574 [details] A diagram showing the next glossary implementation I have attached a diagram of what we are thinking will be the next stage of glossaries. To list a few things specifically: - The current "global" glossary will remain basically the same. We will recommend this be used for more generic terms that can used across an entire instance. We might also look at including the FUEL glossary by default (as part of the global glossary) with Zanata. - Project will automatically have a single glossary enabled that can be edited/added to by maintainers and reviewers/translators in their own language - Projects can choose to disable their glossary to stop translators adding to it - Project maintainers (and in the future Translation maintainers) will be able to specify glossaries form other projects as *prioritised*. - In the editor, translators can access and search all project glossaries across Zanata as well as the global glossary. - In the editor, translators will be able to show only priority glossaries. These would be the current project and any other project glossaries a maintainer has set as priority glossaries. - Translator should be able to edit/add/delete glossary entries from within the editor. This is just the initial features and this can be added to, especially once we have organisations. Happy to hear your feedback.
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-307
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days