Broken translation freezes Yakuake #8

Closed
opened 4 years ago by jstolarek · 13 comments
Collaborator

Basic information

  • TDE version: R14.0.9
  • Distribution: Debian Buster
  • Hardware: amd64

Description

So I've accidentally broken the translation with 95843ec634 but I don't fully understand what I did wrong and need some guidance. The problem is with added lines 328-329, which are intended to provide translation for phrases "Shell" and "Shell No. %n" used to labels tabs with shells in Yakuake. In the sources the original phrases are stored as:

"_n: Shell\n"
"Shell No. %n"

and I translated them as:

"_n: Powłoka\n"
"Powłoka nr %n"

but apparently that's not correct since the text in the program now shows as "BROKEN TRANSLATION Shell". Even worse, attempting to create a new shell freezes Yakuake and the only way to recover is to kill Yakuake from a text console (Ctrl+Alt+F1). How are the plural forms intended to work?

Importantly, I might have caused similar problems in Amarok with commit ac48478ebc, but the package was not yet rebuild so I can't test it.

## Basic information - TDE version: R14.0.9 - Distribution: Debian Buster - Hardware: amd64 ## Description So I've accidentally broken the translation with 95843ec6347637cd0f3a6ae385baf1bd9ddd54f9 but I don't fully understand what I did wrong and need some guidance. The problem is with added lines 328-329, which are intended to provide translation for phrases "Shell" and "Shell No. %n" used to labels tabs with shells in Yakuake. In the sources the original phrases are stored as: ``` "_n: Shell\n" "Shell No. %n" ``` and I translated them as: ``` "_n: Powłoka\n" "Powłoka nr %n" ``` but apparently that's not correct since the text in the program now shows as "BROKEN TRANSLATION Shell". Even worse, attempting to create a new shell freezes Yakuake and the only way to recover is to kill Yakuake from a text console (Ctrl+Alt+F1). How are the plural forms intended to work? Importantly, I might have caused similar problems in Amarok with commit https://mirror.git.trinitydesktop.org/gitea/TDE/amarok/commit/ac48478ebc0f65a154d8e28c27711f2c92cc18e2, but the package was not yet rebuild so I can't test it.
jstolarek added the SL/regression label 4 years ago
Owner

The problem is that the TDE still uses the old way of writing a plurality of translations. It was created for KDE at a time when gettext did not yet provide such a possibility. The newer gettext already includes a way to write plurality of translations, but it is not compatible with the original KDE way.

Therefore, in TDE translations, the notation _n: introduces a plural translation, where this _n: is not to be part of the translated string. Unfortunately, Weblate reports a translation check error for such translations that needs to be ignored.

Your translation should therefore look like this:

"Powłoka\n"
"Powłoka nr %n"
The problem is that the TDE still uses the old way of writing a plurality of translations. It was created for KDE at a time when gettext did not yet provide such a possibility. The newer gettext already includes a way to write plurality of translations, but it is not compatible with the original KDE way. Therefore, in TDE translations, the notation `_n: ` introduces a plural translation, where this `_n: ` is not to be part of the translated string. Unfortunately, Weblate reports a translation check error for such translations that needs to be ignored. Your translation should therefore look like this: ``` "Powłoka\n" "Powłoka nr %n" ```
Poster
Collaborator

I fixed the transltaion via Weblate. Would it be possible to pull it, build the package, and push the fix to the repos?

Now, a few more questions:

  1. Does the difference between the two methods boil down to leading _n: on the first line?
  2. Can the two styles of plural forms be mixed within a single program? As I understand it the _n: form is the new (TDE) one?
  3. How do I know when to use which form?
  4. Are my Amarok translations correct? Some of the plural forms were using _n: already and I left them unchanged. Many were missing the leading _n: and I added it.
  5. Weblate didn't report a translation check error for my fixed translation. Is something else possibly wrong?
I fixed the transltaion via Weblate. Would it be possible to pull it, build the package, and push the fix to the repos? Now, a few more questions: 1. Does the difference between the two methods boil down to leading `_n: ` on the first line? 2. Can the two styles of plural forms be mixed within a single program? As I understand it the `_n: ` form is the new (TDE) one? 3. How do I know when to use which form? 4. Are my Amarok translations correct? Some of the plural forms were using `_n: ` already and I left them unchanged. Many were missing the leading `_n: ` and I added it. 5. Weblate didn't report a translation check error for my fixed translation. Is something else possibly wrong?
Owner

I fixed the transltaion via Weblate. Would it be possible to pull it, build the package, and push the fix to the repos?

Yes, I'll probably do it this afternoon.

Now, a few more questions:

  1. Does the difference between the two methods boil down to leading _n: on the first line?

The format using _n: was long ago designed by KDE as a way to provide a plurality of translations without having to change the format of PO/MO files. The gettext team later proposed and adopted another solution that became the accepted standard.

  1. Can the two styles of plural forms be mixed within a single program? As I understand it the _n: form is the new (TDE) one?

The format using _n: is not a new format, but an old format that TDE inherited from KDE. Therefore, to extract strings to POT templates, we must use an older modified version of xgettext, ie kde-xgettext.

Here is the intention to modify the tde-i18n engine so that we can convert the strings to the new plural format, which is now standard for gettext.

  1. How do I know when to use which form?

In short, if a translation starts with _n: it is always an old format of plural translations. Weblate properly recognizes the new plural format and displays multiple separate edit lines for each plural variant.

  1. Are my Amarok translations correct? Some of the plural forms were using _n: already and I left them unchanged. Many were missing the leading _n: and I added it.

You don't have to worry about translations where _n: was included in the translated string. I'm now testing the automation of repairing such strings, so then I'll do the repair in bulk.

  1. Weblate didn't report a translation check error for my fixed translation. Is something else possibly wrong?

Weblate does not recognize the old plural form of translations proposed by KDE and therefore checks for these translations fail and are reported as requiring attention. Currently, you need to ignore this type of check.

> I fixed the transltaion via Weblate. Would it be possible to pull it, build the package, and push the fix to the repos? > Yes, I'll probably do it this afternoon. > Now, a few more questions: > > 1. Does the difference between the two methods boil down to leading `_n: ` on the first line? The format using `_n:` was long ago designed by KDE as a way to provide a plurality of translations without having to change the format of PO/MO files. The gettext team later proposed and adopted another solution that became the accepted standard. > 2. Can the two styles of plural forms be mixed within a single program? As I understand it the `_n: ` form is the new (TDE) one? The format using `_n: ` is not a new format, but an old format that TDE inherited from KDE. Therefore, to extract strings to POT templates, we must use an older modified version of `xgettext`, ie `kde-xgettext`. Here is the intention to modify the tde-i18n engine so that we can convert the strings to the new plural format, which is now standard for gettext. > 3. How do I know when to use which form? In short, if a translation starts with `_n: ` it is always an old format of plural translations. Weblate properly recognizes the new plural format and displays multiple separate edit lines for each plural variant. > 4. Are my Amarok translations correct? Some of the plural forms were using `_n: ` already and I left them unchanged. Many were missing the leading `_n: ` and I added it. You don't have to worry about translations where `_n: ` was included in the translated string. I'm now testing the automation of repairing such strings, so then I'll do the repair in bulk. > 5. Weblate didn't report a translation check error for my fixed translation. Is something else possibly wrong? > Weblate does not recognize the old plural form of translations proposed by KDE and therefore checks for these translations fail and are reported as requiring attention. Currently, you need to ignore this type of check.
Poster
Collaborator

The gettext team later proposed and adopted another solution that became the accepted standard.

Is that standard documented somehwere? I'm still sort-of guessing how this exactly works and would gladly take a look at the docs.

The format using _n: is not a new format, but an old format that TDE inherited from KDE. Therefore, to extract strings to POT templates, we must use an older modified version of xgettext, ie kde-xgettext.

Ok, so the trend is to get rid of the _n: translations, rather than add them. I'm still not sure whether the two are allowed to coexist in the same file. Apparently, I can't safely add _n: because it potentially breaks things. What about the other way around? Can I remove existing _n: and be certain that nothing will break?

You don’t have to worry about translations where _n: was included in the translated string.

I guess the reason I am worried is because I added _n: to several strings and I don't want the repository version of Amarok to end up broken. Do I understand correctly that you will take care of fixing those?

> The gettext team later proposed and adopted another solution that became the accepted standard. Is that standard documented somehwere? I'm still sort-of guessing how this *exactly* works and would gladly take a look at the docs. > The format using _n: is not a new format, but an old format that TDE inherited from KDE. Therefore, to extract strings to POT templates, we must use an older modified version of xgettext, ie kde-xgettext. Ok, so the trend is to get rid of the `_n: ` translations, rather than add them. I'm still not sure whether the two are allowed to coexist in the same file. Apparently, I can't safely add `_n: ` because it potentially breaks things. What about the other way around? Can I remove existing `_n: ` and be certain that nothing will break? > You don’t have to worry about translations where _n: was included in the translated string. I guess the reason I am worried is because I added `_n: ` to several strings and I don't want the repository version of Amarok to end up broken. Do I understand correctly that you will take care of fixing those?
Owner

I seem to have found the cause.

For Polish, as for many other languages, the plural form expects three variants. However, the current translation contains only two variants.

When I edited your translation and added one more line Powłoka nr %n – yes, the same as the second variant – it started to work properly.

I seem to have found the cause. For Polish, as for many other languages, the plural form expects three variants. However, the current translation contains only two variants. When I edited your translation and added one more line `Powłoka nr %n` – yes, the same as the second variant – it started to work properly.
Poster
Collaborator

For Polish, as for many other languages, the plural form expects three variants.

What are these variants expected to be? In English there are two forms: "Shell" and "Shell No. %n" and these translate one-to-one to Polish.

EDIT: Also, how can I know how many variants are expected so that I can avoid such problems in the future?

> For Polish, as for many other languages, the plural form expects three variants. What are these variants expected to be? In English there are two forms: "Shell" and "Shell No. %n" and these translate one-to-one to Polish. EDIT: Also, how can I know how many variants are expected so that I can avoid such problems in the future?
Owner

The number of plural variants depends on the language. For Polish, as well as for Czech, Italian and many other languages, there are 3. See information about language available in TWTW:

https://mirror.git.trinitydesktop.org/weblate/languages/pl/#information

It is true that the consequence of a bad translation is too fatal, and that it would be good to solve it so that it does not cause an endless loop.

The fact is also that the use of plural translation in this case seems to be not a very good choice, because in this form it is very likely that exactly two variants will always be used.

The number of plural variants depends on the language. For Polish, as well as for Czech, Italian and many other languages, there are 3. See information about language available in TWTW: https://mirror.git.trinitydesktop.org/weblate/languages/pl/#information It is true that the consequence of a bad translation is too fatal, and that it would be good to solve it so that it does not cause an endless loop. The fact is also that the use of plural translation in this case seems to be not a very good choice, because in this form it is very likely that exactly two variants will always be used.
Poster
Collaborator

See information about language available in TWTW:

https://mirror.git.trinitydesktop.org/weblate/languages/pl/#information

This is exactly what I needed - thanks! Now the plural forms make sense.

The fact is also that the use of plural translation in this case seems to be not a very good choice

Indeed. I think that getting this right would require the ability to customize the number of plural forms on a per-translation basis.

> See information about language available in TWTW: > > https://mirror.git.trinitydesktop.org/weblate/languages/pl/#information This is exactly what I needed - thanks! Now the plural forms make sense. > The fact is also that the use of plural translation in this case seems to be not a very good choice Indeed. I think that getting this right would require the ability to customize the number of plural forms on a per-translation basis.
Poster
Collaborator

Any estimate when an updated package will be available in the repo?

Any estimate when an updated package will be available in the repo?
Owner

Any estimate when an updated package will be available in the repo?

Did you edit the translation on TWTW? My test, which I mentioned, was performed only locally.

> Any estimate when an updated package will be available in the repo? Did you edit the translation on TWTW? My test, which I mentioned, was performed only locally.
Poster
Collaborator

Ah, I thought ypu pushed the fix :-) Will edit now.

Ah, I thought ypu pushed the fix :-) Will edit now.
Owner

Translations pushed and merged into a stable branch – building is now underway.

Translations pushed and merged into a stable branch – building is now underway.
SlavekB added this to the R14.0.9 release milestone 4 years ago
Poster
Collaborator

I can confirm that everything works now. Closing.

I can confirm that everything works now. Closing.
jstolarek closed this issue 4 years ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/yakuake#8
Loading…
There is no content yet.