core:text/i18n: number of translatable strings in get() calls.

[mgavioli]

Sorry for the text wall, I think a bit of context is useful. While working on a tool to generate .PO / .POT files from Odin sources, I hit a difficulty.

1. .PO files contain two kinds of entries: the immutable entries, in which a single source language string is matched to a single target language string and the 'pluraliseable' entries in which TWO source language strings (one for the fallback singular and one for the fallback plural) are matched to n target language strings (where n is defined in the .PO header and depends upon the language; in C / C++ this amounts to the difference between calling gettext() and calling ngettext()). Most .PO tooling do not even allow to enter the n translations if there are not the TWO source strings.

2. core:text/i18n calls to the various forms of the get() proc group only provide one parameter for the string to be translated, so there is no 'second string' to be collected in the .PO file for the fallback plural and to mark the entry as 'pluraliseable'.

Additionally, an immutable string is not a singular string (as the number parameter defaulting to 1 may suggest), but a string which will have only one form, which linguistically may be singular ("Account created") or plural ("All temporary files have been deleted"), the point is that it will never change: the number parameter is not simply defaultable, it is actually irrelevant.

The main reason for the second string to be there is that, for strings which may have different number forms and in case the whole i18n / l10n machinery fails (a missing .mo file may be enough for this), there will be fallback strings to cover the plural possibilities, even if in the source language only (which, as a fallback, is assumed to have a simple one/many plural structure).

In practice, for the moment being, I am resorting to rendering as .PO immutable entries the get() calls with no explicit number parameter and as 'pluraliseable' those with an explicit number parameter, conjuring out of thin air a second string like "ADD A PLURAL FORM HERE!", hoping the programmer (this is still programmer side) will go through the initial .POT file once generated, adding all the missing strings. This will allow the translator to add all the pluralisation forms he will need for the specific target language.

Still, I am not convinced this is the way to go and that, sooner or later (better sooner than later), this distinction would/should rather be made at API level, introducing two families of get() calls, one with one text string and no number and one with TWO text strings AND the number.

Comments and/or objections are welcome!

[mgavioli]

Currently, the programmer is expected to always provide only one message string, which is presumably arranged to be generally valid (in the lines of "%d file(s) deleted").

To maintain compatibility with other formats, the job of providing a second (perhaps conventional) string in .po files (to mark then as 'pluraliseable') may be left to the tool generating the .po from the sources, keeping the current number of string parameters.

What is important is to be able to distinguish between messages intended to be immutable and those intended to be 'pluraliseable'.

A simple way to achieve this, which does not disrupt (too much?) the current economy of means of the i18n.get() calls, could be to make the number parameter no longer defaultable, but either absent (i18n.get("My message"), where number is not defaulted to 1, but openly absent) meaning the message is immutable or present with an explicit value (i18n.get("My message", 2)), meaning the message can be pluralised.

Just my 0.02€...

[Kelimion]

I think I get what you mean.
get_immutable(key)
get_n(key, n)
So no more default parameter n = 1.

And get_immutable you call with Message1, which has just the single value entry.
Whereas get_n you'd call with Message1/Plural which sports num_plural entries?

[mgavioli]

Yes, precisely! (possibly get(["section",] "key" [, catalogue]) and getN(["section",] "key", n [, catalogue]) would be more compact?).

Having the "Plural" form in (or in addition to) the key is not strictly necessary and would break the parallelism with Qt Linguist files which do not have it. The "Message" would be generic ("%d file(s) deleted") and, for a proper support of the source language (let's assume it is English), a specific messages_en.mo/.ts/.qm file would be provided by the programmer/translator. This is what Qt Linguist itself proposes/requires and what .ts/.qm files conform to.

On no key match, the getN() call would always return the first (and actually only) key form (as the immutable call would also always do); it would the job of an external .odin source parsing tool extracting translatable string into a .po/.mo message catalogue to provide an additional, conventional, string to comply with the .po/.mo format.

I have replied on Discord too, but at this point I think it is better to collect all observations here. As I said there, I noticed that distinguishing between two calls like get("key", number) and get("key", catalogue) differing only for the type of a non-literal parameter would be rather hard for such an external tool: having two families would make things much simpler.

Thanks for your support!