Page MenuHome

WIP: Misc Localization
Needs ReviewPublic

Authored by Harley Acheson (harley) on Sun, Nov 3, 10:10 PM.

Details

Summary

Some experiments with adding some localization preferences:

There might be some places where these preferences aren't obeyed, but seems to work in most general display cases. But not (yet) while entering keyboard values.

Still trying to see how much work would be involved to complete, but don't have a lot of time to play with it. Might be nice to include options like this once we are are showing international fonts always.

Diff Detail

Repository
rB Blender

Event Timeline

Updating to current state of master. Adding some normalization functions that will be needed later.

Can now edit entries with localized settings:

In the image above you will see that decimal character is set to comma, number grouping is set to period, and negatives are indicated with parentheses. The "location X" shown is small negative number -2.93382. Scale X is 1.245. The amount of vertices is 147,468

It’s nice to improve the support for further internationalization. A few questions/notes:

  • Rather than offering these controls inside Blender, could we not simply follow the system level settings for this?
  • The way you set this is a little technical - could you not just specify a region and let Blender automatically do the right thing? I mean, things like decimal separators and thousands separators are really linked together and depend on your region.

@William Reynish (billreynish) : It’s nice to improve the support for further internationalization.

This is mostly a test of blender itself. I wanted to know how much work and mess is required to do these things. And it looks like not too much. This might be a nice step to take after we align those font symbols, and then use only the international versions. That way we are showing multilingual glyphs at all times and can move toward being better international citizens. LOL

could we not simply follow the system level settings for this?

Yes, instead of adding new user preferences for these we could instead make this a part of Ghost and get these settings from the operating systems. Certainly one possible way of configuring it. But during testing I need to be able to quickly switch between patterns so this was the best way only for now.

could you not just specify a region...

Yes, another way to do that is to specify a locale with these settings grouped inside. Probably not something we want to maintain ourselves though. But if @Bastien Montagne (mont29) incorporates HarfBuzz for complex scripting, that library works well with ICU and that does locales well. And has some routines that might replace some of mine here too.

But no matter how the options are configured we still need to add code to follow those settings. This patch is mostly about exploring how and where to do so.

@Harley Acheson (harley) Indeed, it makes sense. The underlying capabilities here seem worthwhile. But preferably we could allow for setting this in an easier, or even automatic way based on the system OS.

I would be very careful with that kind of changes (talking on usability level here, not code-wise)… I happen to have had to use LibreOffice in French locale, and guess what? By default, you cannot enter a number using the dot . char (which is on our numpad keyboard), you have to switch from the numpad to the main keyboard all the time, this is incredibly frustrating when working in a spreadsheet. Because french locale specifies comma , as numeric decimal separator.

I have serious heavy doubts that supporting things like numerical separators and such has any real interest? As far as I can see, this would only add extra development and maintenance burden, for very little significant improvements.

Not to mention that that patch is already not so small, and it does not cover things like basic (with our own parser) and complex (with python evaluations) inputs, drivers expressions, etc.

I’d rather see time spent on supporting RTL languages and complex scripts tbh. It’s also fairly complicated and involved, but at least it would allow a lot of people around the world to actually be able to use Blender in their own language…

@Bastien Montagne (mont29) - I have serious heavy doubts that supporting things like numerical separators and such has any real interest?

My first interest is in allowing comma for decimal. Ideally allowing either comma or period for decimal during entry (at any time) and then a switch for how it should be displayed.

But once reals are shown with commas for decimal separator then it is nice to show large int numbers grouped with periods, otherwise looks a bit broken. Granted we don't show grouped large number in many places. And. to be fair, it was dealing with those grouped numbers that creates most of the complexity here. Mostly because our string processing code is fairly isolated from user prefs.

As far as I can see, this would only add extra development and maintenance burden, for very little significant improvements.

It doesn't look like much maintenance burden for what I would keep, which is mostly just decimal separation and number grouping. Percentage output pattern is small and seems fairly harmless.

As for significant improvement it would depend on the user's perspective. For many people seeing a number wrong is significant. A good example is me looking at a number like "1.234.567.89". It is difficult for me to read and hard to even understand the magnitude of it with the India-style digit grouping, in this case "123,456,789". As difficult it is for me to deal with a number displayed like that, it is just as difficult for some users to deal with numbers displayed as we do now.

...does not cover things like basic (with our own parser) and complex (with python evaluations) inputs, drivers expressions, etc.

I would drop negative pattern though as that causes too much trouble with changes of ordering. Without that all the fancy numeric input tricks we have should work fine since just replacements before and after parsing.

I’d rather see time spent on supporting RTL languages and complex scripts tbh. It’s also fairly complicated and involved, but at least it would allow a lot of people around the world to actually be able to use Blender in their own language…

Yes, would be nice to do those too, but quite separate issues.

@Bastien Montagne (mont29) the Danish system used comma for decimals and period for thousands separators, just like Germany and some other countries. But on danish keyboards, the numpad has a comma, so it’s no issue. Isn’t it the same for France?

Provided that it becomes more automatic, this could be worthwhile I think. RTL languages could also be done separately.

Next time I get bored I'll take some esoteric stuff out...

  • Removal of apostrophe for decimal symbol
  • Removal of apostrophe for number grouping
  • Removal of all negative number patterns

Then allow simultaneous usage of period or comma as decimal symbol. Then you can enter a decimal with either key but then choose to display it as either one or the other. Without negative number patterns all the fancy routines we use for number handling should still work since nothing will muck with the ordering.

Simplified by removing some less-used options and negative number patterns. Can now enter numbers using period or comma as decimal separator at all times and display it any way you like.

You can enter things like the following and get 5.5

If showing period as decimal you can enter "1,6" and get 7 which makes sense. But if showing comma as decimal it is "1.6" of course.