Grav translation philosophy change

[svatas]

As I am using GRAV more and more and try to get more and more experience with it, I found, that translation model integrated into GRAV is not good. I am not talking about content but about GUI.

I am from Czech Republic and users there are very sensitive if the product is not available in local language - Czech language. Therefore some time ago I prepared Czech translation (via crowdin) and it is available in GRAV as of now.

However the translation is not good - the structure and logic inside is not flexible as it use English as a base. Czech language is slavic language and works with the semantic different way.

When I tried to create a translation (or maybe better - localization) I found some limits, which are not breakable and therefore translation looks very unprofessional.

As the translation is created as just “dictionary database” (see later for explanation) some phrases looks funny and in some cases you must switch to English to fully understand what is error message about.

In many ways the translation phrase is created as a group of joined words reflecting English grammar and it is not transferable to other languages (e.g. Czech language). This is I call dictionary database.

Just some examples :

The translation file starts with the part of INFLECTOR_PLURALS: INFLECTOR_SINGULAR: INFLECTOR_UNCOUNTABLE: INFLECTOR_IRREGULAR: INFLECTOR_ORDINALS:

which is valid for English. Or is possible to be used also in other langauges? Some documentation for it?

In many Slavic languages we have more words for plural e.g.

in EN - 0 pages, 1 page, 2 and more pages - just 2 variants in CZ - 0 stran, 1 strana, 2 - 4 strany, 5 and more stran - 3 variants

I know also that other languages like Slovak or Polish use the same. Now it is not integrated and even can not be managed somehow.

If we are going back to translation file - you can see that when there are translation of time units like hour/hours, minute/minutes etc. as we need 3 variants (1 hodina/2 hodiny/5 hodin)

The tricky translation is also when translating the names of months :

When we are talking about the month itself we can use words like Leden, Unor, Brezen (January, February, March). This is fine. But when we are writing date, you can not use that form of word, that means you need special set of words for dates.

So when we are talking about month, we can say Leden 2020 (January 2020) but for dates we must use 1. ledna 2020 (January 1st, 2020 or 1st January 2020). This is also not covered in the GUI translation (I know that dates are sometimes used from locales on the server, which can handle this)

So this is the translation of GRAV (frontend) but more problems with GRAV admin, as it use more strings and use more combinations and the file is much more complex and bigger.

I was a translator of e.g. Joomla and it was covered. So it is possible, but I feel that there was no direct demand of this functionality in GRAV. So is this the right time to request this?

I can help developers with more examples and even be a tester and fully understand that this is not a project for a week rather for months.

My proposal is to leave the model of joining standalone words to sentences and replace this by full phrases with variables as you can shift the variable inside the sentece and provide the best sentence construction.let me show you an example.

Situation : Provide a string with greeting of just logged in user. The sentence should be something like this :

"Welcome John Doe, nice to see you again on www.mysite.com!"

1) Solution as implemented : Variables [User Name] [Website name]

Standalone strings translation file: GREETING_STRING: Welcome NICE_TO_SEE_YOU_AGAIN_ON: nice to see you again on

String to be shown in GUI : GREETING_STRING + " " + [User name] + "," + NICE_TO_SEE_YOU_AGAIN_ON + " " + [Website name] + "!"

2) Solution firendly to translation Variables %1 which is User name %2 which is Website name

Standalone strings in translation file:

GREETING_STRING: Welcome %1, nice to see you again on %2!

String to be shown in GUI: GREETING_STRING

The second solution is much more convenient as it can bring enough context for translators and they have freedom in translating as I can prepare the translated string much better to suite the needs in my language e.g. translation of example could be done like this:

"Welcome John Doe, nice to see you again on www.mysite.com!"

"Vítejte na stránkách www.mysite.com uživateli John Doe!"

String for Czech language as shown:

GREETING_STRING: Vítejte na stránkách %2 uživateli %1!

In this special case you can see, that for me is important to switch variables comparing to English original as it sounds much better in my langauge. In model we have now implemented, this is impossible (it can be somehow changed in source code). In new model translator can do this without special support from developers and this is responsibility of translator.

Question 1 : Is this explanation clear? Question 2 : Is this acceptable from your side?

As I mentioned this before - this problem is not so big in GRAV itself as it contains just few strings, but rather bigger problem for Admin plugin.

And last argument - I am not a programmer a can not propose any code change just theory behind as I have done...

[ricardo118]

yes this is a known issue with many languages and needs to be revisited, it is a big change and currently was put on backlog due to other priority features.

ill take a deeper look to see the extent of the changes required to make this happen

[svatas]

As I said - this is not a project for one week. Fully understand.

But on the other hand - when I want to use GRAV I will find a limit - the translation, which can harm the feeling from the project (a lot of products available, bringing nearly same functionality...). And therefore I will not use GRAV but some other competitive project. And as this will happen, less and less people will be using GRAV and therefore no sense to improve the product as nobody is using it.... I know, this is Catch-22.

Translation is highly demanded by users but I know a lot of projects which is not dealing with it as this is not a priority for developers. As more and more users is using those tools and they do not speak other language than their mother tongue, this becomes a problem. I vote for setting higher priority to that translation project as it can significantly improve the overall feeling from GRAV.

Therefore I am happy to see that you are even thinking about change as it brings more light to the "problem". For me the GRAV is perfect tool. Even I am a big fan of Joomla but not always as GRAV is much better in small webpage projects and can also bring new ideas to Joomla...

Thank you.

[ricardo118]

hey @svatas so i spoke with @rhukster regarding this and we are both happy to get at least these INFLECTORS things moving along. Do you happen to have joined our discord? If you are willing to provide me with some help/insight/testing we could get this thing going.

[svatas]

Just joined discord

[petira]

I add that this does not only apply to Grav, but also plugins.

I encountered a problem with Czech pluralization in the SimpleSearch Plugin, but the proposed change was not applied (https://github.com/getgrav/grav-plugin-simplesearch/pull/187#issue-412617183).

In this context, I refer to the issue https://github.com/getgrav/grav/issues/903#issue-160384635.

[rhukster]

That #187 was merged

[petira]

That #187 was merged

@rhukster look here: https://github.com/getgrav/grav-plugin-simplesearch/pull/187#issuecomment-706106240

[svatas]

Dear all,

after while I am asking about this improvement again. It was first mentioned in June 2020, but no real output from this until now. Are there any plans how to solve this? I fully understand what is behind and an effort which must be invested into this. But from my perspective this is a big problem of GRAV as of now.

I fully understand that for english speaking person this is not so important, but for the rest of non english speakers this could be a pain. For me is this very sad as there was no real activity done to improve the status.

Once again - is there any chance to change the philosophy and bring this project further?

[petira]

Hi!

I agree with @svatas. Pluralization is different in the Czech language (and in others as well) and it is desirable to take it into account in translations.

I am also ready to be helped.

[lufog]

I'll just leave it here: https://projectfluent.org

[mahagr]

I added better translations to our Grav 2.0 list. Right now a lot of the strings aren't translated at all and when they are, the translations are often lacking or too simple.

[petira]

Thanks for the feedback.

Specifically in Czech, all strings in both Grav and Admin Panel are translated. Also in several major plugins.

It might be worthwhile to promote Crowdin more, because a lot of users send translations via Pull requests.

[Sogl]

I've been waiting for this enhancement for a long time.

[svatas]

Dear Team,

my original post was written 4 years ago. The situation is still the same. Are there any plans to somehow deal with this "translation hell"?

I know, that the last feedback was - lets wait for version 2.0, but still - we are 4 years older and no change in that, even no news about change.