Jan
23
1 day ago
started
started time in 13 hours ago
Jan
22
2 days ago
started
started time in 1 day ago
started
started time in 1 day ago
Jan
21
3 days ago
Activity icon
fork

Wesley-yang forked getgrav/grav

⚡ Modern, Crazy Fast, Ridiculously Easy and Amazingly Powerful Flat-File CMS powered by PHP, Markdown, Twig, and Symfony
Wesley-yang MIT License Updated
fork time in 2 days ago
Activity icon
issue

lufog issue comment getgrav/grav

lufog
lufog

Grav translation philosophy change

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] + "!"

  1. 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...

Activity icon
issue

petira issue comment getgrav/grav

petira
petira

Grav translation philosophy change

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] + "!"

  1. 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...

petira
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.

Activity icon
issue

svatas issue comment getgrav/grav

svatas
svatas

Grav translation philosophy change

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] + "!"

  1. 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...

svatas
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?

Activity icon
issue

IamSAB issue getgrav/grav

IamSAB
IamSAB

Checkboxes validation bug

The checkboxes field only is valid when all options are checked. Selecting only some or no options will render it invalid and the form won't submit.

hobbies:
  type: checkboxes
  label: Hobbies
  options:
    soccer: Soccer
    rugby: Rugby
    biking: biking
   swimming: Swimming

As you see, there is any validation defined, the field is not even required. Is that a known bug?

I use that field type inside a flex form in the admin backend,

started
started time in 3 days ago
Previous