Implemented TranslationServer::format_integer

[MuffinManKen]

At the moment this only supports a single locale ("en"), but I wanted to get some feedback on the code first to see if I'm headed in a Godot-compatible direction.

Addresses #28660

[MuffinManKen]

If everything looks okay, I think this can be merged. As mentioned in the commit log, not all locales have data but:

1. There's a commented line for each locale missing data so it's easy to track/update
2. These locales will end up getting the en_US values, which should be correct more often than not.

[akien-mga]

The feature is interesting, but we don't use the C++ STL in Godot's codebase, so you would have to do it without sstream and std::locale.

[Calinou]

@MuffinManKen Bump 🙂

In a future PR, we could also add currency sign information to each locale; this way, currencies can be formatted with the correct sign position. In some languages such as English, the currency symbol is placed before the number, but in many other languages, it goes after the number. See vue-currency-filter for examples of other properties that could be added (such as a decimals separator when TranslationServer::format_float is implemented).

Formatting currencies will require the user to specify the currency sign, which could be an optional second parameter to the TranslationServer::format_float function (and perhaps TranslationServer::format_integer). Still, this is low-priority as the editor doesn't display currencies anywhere.

[MuffinManKen]

@Calinou Agreed. There's a lot of room for improvement here. I've been swamped with other work, but definitely plan to get back to this.

[akien-mga]

Before doing too much work to improve the PR, we need to reach a decision on whether this is a wanted feature and the right approach to do it.

The feature makes sense to me, but reimplementing a table of all locale-specific number formatting sounds pretty tedious and overkill. Beyond possible separators in large numbers, there's also different decimal separators depending on the locale. Bad handling of decimal separator has actually plagued Unity games for years on Linux due to them picking up the system decimal separator (e.g. , on fr_FR.UTF-8) and trying to parse JSON with it... So in a sense it's likely safer not to provide too much functionality out of the box in this regard.

If we really want such feature, it likely makes more sense to defer the handling of all locales' particularities to a dedicated library, but I'm not sure we would want to pull in a full blown i18n library for that. Maybe we can defer to OS calls if they provide this information for the user's current locale.

[MuffinManKen]

I don't think that it's often needed to have the functionality of a full i18n library. Parsing data based on the current locale seems like a really odd thing to do, but I suppose that's an artifact of trying to do localization "automagically".

The goal of this PR was to make it easier for developers to explicitly format numbers in a locale-aware way. If this and float/money formatting were provided I think that would cover 95% of what most developers would need.

I don't like the idea of using the OS's current locale. I see 2 problems with it right away:

1. Testing. If I, or my testers, want to make sure my game doesn't blow up when set to Russian, I don't want to change the OS's locale to do that.

2. It's not uncommon for players to set their game locale to something different than what their OS is set to.

3. It would be inconsistent. If my game doesn't support the same locale as the OS, the user would end up with all of my content based on the whichever locale they choose in-game, but anything provided via these localization calls would use their OS locale.

[aaronfranke]

Since this PR requires further discussion, you should open a proposal which explains example use cases and how this approach will solve the problem.

This PR is not good as-is due to the above comments about STL, so I'll close this. After a proposal is discussed and approved, this can be re-opened, or you can open a new PR.