Reorder parameters in tr_n and related methods

[dalexeev]

Make n parameter first and plural_message optional in the following methods:

• Object.tr_n();
• Translation._get_plural_message() (only order);
• Translation.get_plural_message();
• TranslationServer.translate_plural();
• TranslationServer::tool_translate_plural();
• TranslationServer::doc_translate_plural();
• TTRN(), RTRN(), DTRN().

---

When using translations based on identifiers, the plural_message parameter is not needed, so it makes sense to make the n parameter first and plural_message optional. In my opinion, this is logical and convenient, since the n parameter is "the most required" parameter in the tr_n function.

These changes are in PR #41519, but it's very likely that #41519 might not make it into the 4.0 release. This PR will avoid breaking compatibility if #41519 is implemented later. Also, it will be useful if someone decides to implement a custom translation format based on identifiers (it's possible, i'm going to implement my format instead of CSV).

[dalexeev]

For TTRN(), RTRN(), DTRN() I think plural_message should be left required? (Otherwise, this regular expression also needs to be corrected.)

[dalexeev]

This PR does not break compatibility with 3.x, but breaks with 4.0 beta 3.

[timothyqiu]

I can see the original intention of reordering parameters: in order to make plural_message optional, it has to be after non-optional arguments. So moving n to the first becomes a requirement.

But what's the reason for making plural_message optional? #41519 says it's unused when using identifier as message id. TBH, I think using identifier as message id is another layer of abstraction on top of tr functions and po/csv files. This usage should not affect how the underlying function works.

tr_n("%d day ago", "%d days ago", days)  # As regular text.

tr_n("DAYS_AGO", "DAYS_AGO", days)  # Repeat the identifier: this is also confusing when extracted to POT.

# Make a wrapper to avoid repeating yourself.
func tr_identifier(identifier: String, n: int) -> StringName:
    return tr_n(identifier, identifier, n)

tr_n() uses the same order as the pseudo standard ngettext() function. I don't think it should be reordered.

[dalexeev]

Make a wrapper to avoid repeating yourself.
func tr_identifier(identifier: String, n: int) -> StringName:
    return tr_n(identifier, identifier, n)

This is less convenient because GDScript does not support user-defined global functions. It will be at least Util.my_tr_n.

tr_n() uses the same order as the pseudo standard ngettext() function.

Compliance with standards is good, but is it really that important in this case? Should we follow the standard if it's less convenient?

I think those who are used to the order of arguments in ngettext will quickly get used to the different order in tr_n. At most they will be a little confused the first time, but the function signature hint and type mismatch will help fix the error.

At the same time, those who use CSV and perhaps don't know about ngettext at all will be inconvenienced by the extra argument every time.

[timothyqiu]

Yeah, compliance with standards is good to have but not a requirement. We already merged the context feature from p*gettext() into tr() and tr_n().

My main argument is that tr functions are designed for plain texts instead of identifiers. I think using identifiers in tr() works by coincidence, it does not mean tr_n() should work for identifiers too.

Threre will still be problems after reordering the parameters. For example, if we were to implement context support for CSV files, users still have to write something like tr_n(days, "DAYS_AGO", "", "calendar").

I think it's better to use a wrapper function for translating identifiers.

[dalexeev]

My main argument is that tr functions are designed for plain texts instead of identifiers.

Yes, it looks more readable with original strings than with IDs. But in my experience, a lot of people use tr function with CSV and IDs instead of .po files, especially those who don't speak English. And if the original language has more than one plural form, IDs are preferred, since you simply cannot pass all forms to tr_n.

For example, if we were to implement context support for CSV files, users still have to write something like tr_n(days, "DAYS_AGO", "", "calendar").

Context is needed to disambiguate when the same phrase in the source language is translated into several different phrases depending on the context. However, IDs must initially be unique, the context is included in the ID name. Therefore, this scenario seems impossible in practice. (It should be DAYS_AGO_CALENDAR or something similar.)

I think it's better to use a wrapper function for translating identifiers.

The wrapper function is one of the possible solutions to the problem, but it's less convenient to use at the moment, due to the limitations of GDScript. Also, if we can make the standard function more convenient, that looks like a better solution, I think.

[dalexeev]

This PR breaks compatibility with 4.0 beta, add the label please.

[dalexeev]

Waiting for Godot 5. :|