Locale Glossaries (Global glossaries across projects)

[ocean90]

From https://glotpress.trac.wordpress.org/ticket/361

To keep the translations consistent through out all projects in a language, there should be just one glossary per locale.
Today glossaries are per project making it difficult to maintain them (when you add a term to one project's glossary, you'll want to add it to all the other projects too).
However, each project may have its own specific glossary.

---

Currently the glossaries are assigned to a translation set of a project. But GlotPress also inherits a glossary from a closest parent project when there isn't one existing for the current translation set, see [1068].

I don't think that GP should loose the ability to have glossaries per projects, I'd rather have one global glossary per locale which is used as a base for each project.

[arhipaiva]

Clearly, one giant universal glossary will not do.
Equally true, project glossaries are too tedious to maintain and of limited utility to translators of other plugins in the same field. Only the biggest unique projects would require own glossaries.

Something in between is called for.
I suggest topic or field of expertise related glossaries. There is a need to unify the terms among all eCommerce plugins, among all stats/analytics plugins, among all social media related plugins, among all security plugins, etc.
Based on practical needs (outlined below) I would like to see the following (- though I doubt it will happen…)

A hierarchy of glossaries:

1. A general glossary covering the core terms of WordPress. This would apply automatically to all plugin and theme translations within a locale. It cannot be be made too large.
2. Several topic centered glossaries, each covering a field/topic in which there are multiple plugins.
   -- When a translator starts a new translation project he/she would see the terms from the general glossary already applied to the project. Then he/she would tick which of the topic related glossaries he/she wants to integrate into this project. One or several.
   --- (This would introduce a likelihood of conflict and thus there is a need to present multiple translations in translation suggestion field to choose from…)
   -- Topic glossaries could start as project glossaries and could be promoted to topic plugin status, based on need and quality.
3. Project related glossaries will be needed as entry level glossaries.

Details, practical needs, examples
I am a translator (GTE) of several plugins and some themes. Created a glossary of some 400 terms to standardize the usage and style. 400 is too many and at the same time it is too little. 400 is too many for a general glossary of core terms in WordPress. And it is too small to include specific terms from various fields of expertise.

Several English terms have multiple translation suggestions. This is due to different translation needed in different context. Therefore, to automatically apply a translation it must have a concise general glossary or/and automatic translations must present multiple possible translations, maybe formatted in a coherent way, for example: item -> [kohde, nimike, tuote, kohta, merkintä, jne].

[ocean90]

Relevant discussions on Slack:

• https://wordpress.slack.com/archives/glotpress/p1462527274000450
• https://wordpress.slack.com/archives/glotpress/p1462900098000480
• https://wordpress.slack.com/archives/glotpress/p1462900128000482
• https://wordpress.slack.com/archives/glotpress/p1465320616000098

A summary will follow.

[ocean90]

This is a summary of today's chat: https://wordpress.slack.com/archives/glotpress/p1475600842000583

• We call them now Locale Glossaries, the existing glossaries are Project Glossaries.
• Locale glossaries are available at /languages/de/glossary/default (or /languages/de/default/glossary).
• We'll use the existing database schema and use a "shadow translation set". It's basically a set where project id is set to 0. The glossaries table gets a new colum 'type'.
• Example database entries:
  • /languages/de/glossary/default (or /languages/de/default/glossary)
    glossary: id: 1, translation_set_id: 1, description: Locale Glossary, type: locale
    translation_set: id: 1, name: German, locale: de, slug: default, project_id: 0
  • /projects/wordpress/de/default/glossary
    project: id: 1, slug: wordpress, ...
    glossary: id: 2, translation_set_id: 2, description: Project Glossary, type: project
    translation_set: id: 2, name: German, locale: de, slug: default, project_id: 1
• A user should only see terms from a locale glossary unless the term is different in the project one.
• Duplication between both types should be avoid.