Proper handling of UI messages for translation (i18n) in CPP code. #92758

New Issue

Bastien Montagne · 2021-11-02T16:27:05+01:00

Bastien Montagne commented

2021-11-02 16:27:05 +01:00

'Generated' strings (e.g. using C-style printf strings) need to be known (as much as possible) from translators as a unique, complete single item, not as chunks of strings patched together when building the final UI message.

E.g (from AssetCatalogDropController::drop_tooltip_asset_catalog in asset_catalog_tree_view.cc):

return std::string(TIP_("Move Catalog")) + " '" + src_catalog->path.name() + "' " + TIP_("into") + " '" + catalog_item_.get_name() + "'";

This will generate two completely unrelated messages "Move Catalog" and "into".
Move Catalog could very likely also be an operator name, or a button label, that would require a different translation.
into might have ten different ways to be translated in other languages, how do they choose? What if many places use that single into message?

A C version could be e.g. (pseud-code obviously):

return BLI_sprintfN(TIP_("Move Catalog '%s' into '%s'"), src_catalog->path.name(), catalog_item_.get_name());

This will generate a full specific message "Move Catalog '%s' into '%s'".

Note that this is not only an issue of disambiguation, it is also a critical point for many non-latin languages (RTL languages, languages using alternative signs to quote, etc.).

'Generated' strings (e.g. using C-style `printf` strings) need to be known (as much as possible) from translators as a unique, complete single item, not as chunks of strings patched together when building the final UI message. E.g (from `AssetCatalogDropController::drop_tooltip_asset_catalog` in asset_catalog_tree_view.cc): ```CPP return std::string(TIP_("Move Catalog")) + " '" + src_catalog->path.name() + "' " + TIP_("into") + " '" + catalog_item_.get_name() + "'"; ``` This will generate two completely unrelated messages `"Move Catalog"` and `"into"`. `Move Catalog` could very likely also be an operator name, or a button label, that would require a different translation. `into` might have ten different ways to be translated in other languages, how do they choose? What if many places use that single `into` message? A C version could be e.g. (pseud-code obviously): ```C return BLI_sprintfN(TIP_("Move Catalog '%s' into '%s'"), src_catalog->path.name(), catalog_item_.get_name()); ``` This will generate a full specific message `"Move Catalog '%s' into '%s'"`. ------------------------- Note that this is not only an issue of disambiguation, it is also a critical point for many non-latin languages (RTL languages, languages using alternative signs to quote, etc.).

Bastien Montagne commented

2021-11-02 16:27:05 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Bastien Montagne commented

2021-11-02 16:27:05 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2021-11-02 16:27:59 +01:00

For now, I would suggest that Cpp code uses standard C printf-like functions to build their custom/dynamic UI messages?

For now, I would suggest that Cpp code uses standard C `printf`-like functions to build their custom/dynamic UI messages?

Bastien Montagne commented

2021-11-02 16:28:35 +01:00

Added subscriber: @JulianEisel

Hans Goudey commented

2021-11-02 16:34:13 +01:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2021-11-02 16:34:13 +01:00

The issue with BLI_sprintfN is that it returns an allocated string output, meaning no small size optimization, and requires calling free later on.
Using std::string is so much nicer than that, because of RAII, etc.

Maybe a better solution would be a string format function with a std::string output.

The issue with `BLI_sprintfN` is that it returns an allocated string output, meaning no small size optimization, and requires calling free later on. Using `std::string` is so much nicer than that, because of RAII, etc. Maybe a better solution would be a string format function with a `std::string` output.

Paul Larson commented

2021-11-02 17:35:58 +01:00

Added subscriber: @GeorgiaPacific

Damien Picard commented

2022-09-26 19:41:45 +02:00

Added subscriber: @pioverfour

Damien Picard commented

2022-09-26 19:41:45 +02:00

For the record, after trying to mitigate some string issues in D15996, a talk with @HooglyBoogly hinted at the possibility to replace BLI_sprintfN() with fmt::format(), which is already used in Blender and could be generalized to more C++ code for this purpose.

This library has the extra advantage that format arguments can be numbered, and reordered in translations if needed.

For the record, after trying to mitigate some string issues in [D15996](https://archive.blender.org/developer/D15996), a talk with @HooglyBoogly hinted at the possibility to replace `BLI_sprintfN()` with `fmt::format()`, which is already used in Blender and could be generalized to more C++ code for this purpose. This library has the extra advantage that format arguments can be numbered, and reordered in translations if needed.

Bastien Montagne added this to the User Interface project 2023-02-09 15:34:10 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Proper handling of UI messages for translation (i18n) in CPP code. #92758