taxonomies not truly multi-lingual

[replayshot]

Currently, the way taxonomies are setup, the different language version of each taxonomy do not know about each other. For example: I have a page with taxonomy (color), so if I go to one category, the url is for ex: /color:blue Then I translate the page to German and my color for this page goes from blue to blau. So if I go to the color page now it has url /de/color:blau

However /de/color:blue also exists and it should not. Grav should know that the de/color:blau is equivalent of en/color:blue

With the taxonomies not being multilingual in true sense, with each new taxonomy you introduce non-content pages to your site. So if you have 5 languages and 5 taxonomies for each, you will end up with 5 5 5 possible page urls instead of just 5 * 5.

The way I see it, the issues arise mainly in the SEO area:

• hreflang meta tag for en/color:blue would be es/color:blue, de/color:blue etc. (these pages should not exist)
• switching languages with language switcher has the same problem

Here are my thoughts:

• there can be multiple taxonomies (ex: color, category, tag etc.)
• each page can have 0 or more of these taxonomies
• each taxonomy type (ex: color) content (ex: blue, blau, azul) is independent of each other and each language page does not necessarily have to have the same amount of taxonomy content
• if there is a finite number of taxonomy content (ex: colors - let's say you have 20 colors - this manual look up table would probably make sense)
• if there is an unknown number of taxonomy (ex: tags - each page can have random tags and there can be 1000s of tags - the look up table construction could be quite challenging)
• if we use the admin plugin interface to translate the taxonomies - I can see the mapping working somehow
• however, if we use already translated files (meaning, you just upload files to the server) - this is the challenge of how to actually tell grav that en/color:blue is the same as es/color:azul and de/color:blau

We can probably assume that majority of blogs/pages will follow this rule - that the taxonomies match between languages - if there is blue in english, there will be blau in german etc.

Some ideas: i would just have single language taxonomy and handle the slug/title translations per langauge if we have lookup table for blue, if you have de/xxx/color:blau, the lookup would automatically turn it to blue

[replayshot]

Just some more findings from my research. From what I understand, when Grav page is loaded, it knows nothing of the localized versions (slugs) of the other pages and it only uses rawRoute() to redirect, so if there is a /en/category:blue it would know that there is /de/category:blue, but then the problem arises that the system will not redirect because it does not know that category:blau is a language variation of category:blue.

[replayshot]

I have a temporary solution. It is not pretty, but it does work for a finite number of taxonomy values.

What I did for a color taxonomy:

- add a language specific array to languages.yaml (LOOKUP: [blue, black, red]) - for each language
- grabbed the lookup array based on the current language - {% set lookup = langobj.getTranslation('en','THEME.LOOKUP',true) %} - so if you have a url /de/color:blau - you will end up with a german version of the array
- created a custom twig filter to do array_search which would then return me the index of the color
- then ran through all the languages available and return their corresponding value from the languages.yaml based on the index
- after that just modify the uri.params part of the url which you are trying to link to by using the appropriate retrieve color string

[hotdoy]

That's a really interesting issue I've been having as well. I like the single language taxonomy idea and it fits with the Grav patterns...

• Create page in default lang.
• Save page as other lang.
• Go to a special taxonomy section where all taxonomies are displayed in a table where you can add translations for each supported languages.

Another way would be to prevent the addition of new taxonomy value from a page and only allow ones that already exists from the taxonomy table. It's a bit more of a chore for authors but sounds like something nobody would complain about (can't be worse than Shopify)