Tx accepts only "Plural-Forms: nplurals=1; plural=0;\n" on ja_JP but it's cause of fatal issue of po fiiles

[ponsfoot]

Please allow to specify plurals definition as follows on ja_JP:
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

Currently, Tx accepts only "Plural-Forms: nplurals=1; plural=0;\n" on ja_JP but it can be cause of fatal error of po files.

If source strings are defined like follows:
msgid ""
"Are you sure that you want to permanently\n"
"delete the selected file?"
msgid_plural ""
"Are you sure that you want to permanently\n"
"delete the %u selected files?"

source: Thunar→xfce-4-10

it requires "Plural-Forms: nplurals=2; plural=(n != 1);\n".
Otherwise, Tx drops existing strings as for plural strings.
It's a cause of fatal error of po files.

Locale:" ja_JP
Resource: Thunar→xfce-4-10
https://www.transifex.com/projects/p/xfce/language/ja/?project=43369

BTW, Does Tx have to specify plural definitions explicitly?

[diegobz]

Hi @ponsfoot,

Transifex tries to keep the languages settings/definitions accordingly to Unicode[1]

It's known the Japanese language doesn't have plurals, so you probably should be fine using it like it is. It shouldn't cause any problems.

There is no way you can customize the plural equations at the moment, but you really shouldn't. :)

[1] http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html

[ponsfoot]

Hi diegobz,

Did you see the example which I reported?:

msgid ""
"Are you sure that you want to permanently\n"
"delete the selected file?"
msgid_plural ""
"Are you sure that you want to permanently\n"
"delete the %u selected files?"

That is, 'msgid_plural' includes %u specifier and it's not in 'msgid'.
In this case, po files should be defined to allow plural strings regardless of the language plural rules.
When I translate this po file according to original honestly and push to Tx, po file is broken and it causes build failure of the software.

There is a workaround, however, should Tx restrict the original source's style?
I cannot see that there are any reasons to do so.

[mpessas]

@ponsfoot Since Japanese only have one plural form -- and this is what the plural equation says -- you will have to specify only one translation for pluralized msgids, too. This is how gettext works.

[ponsfoot]

@mpessas

OK, I understand that you have no mind to correct this issue.

This is how gettext works.

gettext works properly if this po file is pushed without Tx.

[mpessas]

@ponsfoot I was referring to the semantics of gettext, not whether this causes syntax errors. All projects I know of use one language for Japanese, like django and bash and map all plural rules to one translation. This is what msginit returns by default, too, for japanese.

[diegobz]

@ponsfoot Yeah, I understood what you mean in the first place and I did notice the pluralized source string.

The thing is that if you add an equation that allows plural rules in Japanese, you will enforce to get always a plural translation, for any pluralized string you have across the whole fine.

For instance, for strings like:

msgid "Sending file"
msgid_plural "Sending files"

You would require the translator to add 2 identical translations for it. This is not the way to translate stuff to Japanese. I'm just pointing out that the solution you found, although it works for you, in general it's problematic. ;)

Now, If you really want to support the %u placeholder even for Japanese, I would suggest you to probably turn that pluralized string into 2 separated normal strings and hold the logic of each one to display in your own code.

[ponsfoot]

@mpessas
I already mentioned that this issue occurs on the project Thunar (of Xfce) and the reason of this issue is unrelated to the language plural rules, actually.
The existing and completed ja.po isn't invalid for gettext because gettext doesn't care each language's plural rules.

I know (also you may already know) this is a rare case.
I have already modified its ja.po to be acceptable to the Tx.

So, that's all in the past now for me.

Thanks

[ponsfoot]

@diegobz
You should understand that this issue doesn't occur if we don't use Tx.

[diegobz]

@ponsfoot Indeed, because it tends to do not support specific problematic solutions.