Interesting. I'll take care of this.

Hello Peter,

Actually I had a look at GIMP interface, where are we actually seeing such text?
I mean, yes units are used in various places, like to give the position of the cursor on the canvas, or creating a new image, scale the image, various tool options, etc. But each time, this is only a dropdown list which shows only the abbreviation once selected. I still have to see a "32 inches" text.

The only such texts we have are for pixels, and not for any other unit. Even when you have a unit dropdown list, with under it a "XXXxYYY pixels", when you change the dropdown selection, the subtext stays pixel (ex: Scale Image dialog), and multi-plural cases are properly handled with ngettext() calls there.

So if the only usage is in dropdown lists, well it has no meaning to care much about adding more plural cases.
Also I wonder: 1x5 inches = 1x5 palec? 1x5 palcov?

in slovak plural forms depend on second number 1x1 palec 1x4 palce 1x5 palcov

Thanks Peter,

but you only answered the minor question and left out the main question: where do you actually see such text in the GUI? Or is it only something you saw in the po file?

Because I couldn't actually find anywhere with these units. They seem only used as dropdown list item's labels or such (where basically singular/plural forms do not matter). So are these actually used somewhere where it looked like ugly localization? Because otherwise that does not really look like a real issue.

I am dont know where these strings in gimp I only translate it. I known only, that is problem with two separate string singular and plural because othe languages can have more then 1 plural form.

Hi Peter,

thanks for the answer. That's what I thought. Well the problem is that they are not "normal" strings. When I looked at the code, I discovered why they did so, and not the usual gettext plural syntax.

msgid "pixel"
msgid_plural "pixels"
msgstr[0] "palec"
msgstr[1] "palce"
msgstr[2] "palcov"

The split plurals are because of code design. Obviously not a very good code design since they should have taken plural syntax into account.

I have looked at the code though, and know how the code structure may be updated to use gettext plural syntax. That's not too difficult. But it will still take time, because it involves a good piece of code in a particular file, then in various files using these units, and some logic change to use these units differently, with value-context awareness, all over the place.

My only concern is that I could not see any single part of our program which actually uses the plural strings and need value awareness! It looks to me that it is mainly used as dropdown list items where singular is always used anyways. Never into actual text with integers.
So it means that I would waste hours to change a whole logics which is basically never used. Thus I think that's not worth it *for now*, at least not until we do more use of these units.

As a consequence, I will set the importance of the bug to "low". This is still a bug, and I understand that from the translator's point of view, it looks ugly design (and it is), but in the end program, the plurals don't really matter anyway, so don't worry. Just use any plural form (whichever one), and leave a translator comment in your po files, with this bug id as a reference to explain why you can't set plurals properly.
If anyone discovers a part of the program where unit plurals are actually used in a contextual manner (with integer values), then I will prioritize up the bug again. :-)

All that, and an API change for no real reason. We should just ignore
this minor problem imo :)

Well that's still ugly code design, in a way that we could consider it a "buggy" design, even though it is fortunately a harmless one. :-)

I'd say we keep it open for now.

Maybe another resolution to this bug could be to actually remove any plural support. :-) That would be acceptable too, in my opinion.

Taking the exact plural syntax into account is almost impossible to
do in an API that allows for registering strings. I think we should
handle this like we handled all previous requests for better unit
translation and simply call it WONTFIX.

Hi,

that's not impossible. That would just be a technical API. Basically you would just define the plural rules when you register your strings (same as gettext does, when you register the rules for your language in the following manner: "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n").

Anyway we can call it a WONTFIX if you want. But I still feel that the design is very wrong for this piece of code. So I would not be against leaving this ticket lying around, even if for a long time, at least for reminding us. Because on the long term, I think something would have to be done for it. That is not necessarily making it a nice plural-aware unit API; it can also be about simplifying the API to only handle singular, getting rid of all plural forms, and be clear from the start that this is not about localizing some units and following language rules, but just to be able to propose units to people in a way that everyone can understand which unit it is.

A million years ago when we did that API nobody had a clue about this and
nobody complained until much later :) I don't say that what we do isn't
wrong, I'm just having doubts that it's worth the effort. A possible
solution would be to have

gimp_unit_get_plural (unit, number);

And some complicated UI in the unit editor to have users define
their new units with multiple plurals.

For proper value-awareness support, I would just do:

gimp_unit_get (unit, number);

instead of one _get_plural() and one _get_singular(), because plural definitely means something different depending on languages. For instance in English, 0 is plural. But in French, 0 is singular. So how would we call it in our code? With _get_singular() or _get_plural()? On the other hand, calling gimp_unit_get (pixel, 0); the language rules just return the right value. :-)

Also I totally understand that years ago, nobody cared about plural forms, nor localization much. That's same for all software. That's not a critic. What is done is done. And I agree it is not worth the effort right now, because there are far more urgent. As I said above, I won't work on it myself, at least right now.

But I have the hope that GIMP will become very stable, and have more developers. And this day, we can also improve small things like this. :-)

So I would personally prefer it open. Now you are the boss. And also we wasted already too much time discussing whether we close or not. Just do it, if you really don't agree with me, or keep it if I am convincing. No need to discuss the matter again at this stage. ;-)

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/434.