Hi Miriam

These settings are not controlled by Studio but rather Studio picks these up from the 'Region and Language' settings in Windows.  You can access this by going to: Control Panel\Region and Language:

If you want to make any adjustments to the default settings you will need to do it here and then restart Studio for the settings to take effect.

Having said that autopropagation doesn't work at all well when I do this:

Compared to the defaults which perform correctly:

I guess the customisation of regional settings isn't such a good idea anymore.  Not sure how well it worked in the past but clearly there is a problem here.  I think the best solution has to be to support more control over how numbers are handled rather than rely on the windows settings, but this isn't going to be anything we see soon.

Maybe go and vote for this one which covers the same topic I think:

https://community.sdl.com/solutions/language/translationproductivity/translation-productivity-ideas/i/trados-studio-ideas/autolocalisation-of-numbers

To be honest, this is the very first time in my carrier I hear about this "standard".

I'm afraid, you're out of luck in Studio with automatic numbers replacement according to this "standard". Studio supports only language-specific formats in the automated numbers localization. It sets the format according to what you can see in Region and Language settings in Control Panel. There is no way to configure this automated numbers localization to use other format.

You need to use some search & replace trickery to achive what you want.

Unknown said:

It's quite simple: Trados changes 1.234,56 to 1,234.56. That is no good. It should be 1234.56 or for numbers with more digits, there should be thousands separators of a non-breaking space. It is THE international standard and REQUIRED by all my clients.

Hi Paul Carmichael 

Quite interesting but not anything I've seen before.  I get it when the four digits relate to a date, 2017, 1999 etc. but I think it becomes very unclear and must only be used by very few people in other situations.  At least 20 years as a Civil Engineer and I've never seen this, nor would I have accepted its use.

However, all that is irrelevant if this is what your client wants!

I suggest you allow Studio to do what it wants and then search and replace the target numbers afterwards using regular expressions to get what you want.  Or use the regex autosuggest provider to do it on the fly as you work... although I'd do it afterwards so you can more easily QA check to make sure your numbers are correct etc.

If you want a better solution then please suggest it in the ideas site as there is no other way it'll happen -  http://ideas.sdl.com

Regards

Paul

Unknown said:

It's quite simple: Trados changes 1.234,56 to 1,234.56. That is no good. It should be 1234.56 or for numbers with more digits, there should be thousands separators of a non-breaking space. It is THE international standard and REQUIRED by all my clients.

Hi Paul Carmichael 

Quite interesting but not anything I've seen before.  I get it when the four digits relate to a date, 2017, 1999 etc. but I think it becomes very unclear and must only be used by very few people in other situations.  At least 20 years as a Civil Engineer and I've never seen this, nor would I have accepted its use.

However, all that is irrelevant if this is what your client wants!

I suggest you allow Studio to do what it wants and then search and replace the target numbers afterwards using regular expressions to get what you want.  Or use the regex autosuggest provider to do it on the fly as you work... although I'd do it afterwards so you can more easily QA check to make sure your numbers are correct etc.

If you want a better solution then please suggest it in the ideas site as there is no other way it'll happen -  http://ideas.sdl.com

Regards

Paul

Hi Paul Carmichael,

As you pointed out, the format you want has been an international standard since 2003 ("Current standards" section of https://en.wikipedia.org/wiki/Decimal_mark).

I also wanted to change Studio's number and date formats in the past. It was one of the first things I wanted to do when I started using Studio many years ago.

But SDL doesn't seem to have the money to hire the enough coders. So you learn to live with the bugs and limitations and figure out workarounds.

And you curse when a new release comes out and new problems are added due to side-effects of the changes.

So I completely sympathize with you. We all have changes that would make Studio better for us.

If there were more Studio users, then SDL would have more money for coders. But there are probably many users who think Studio is already too expensive.

So if SDL invested in more coders to handle bugs and rewrite large sections of old code, would it attract more users and increase its revenues to pay off the investment?

Could SDL increase the price of Studio because it was now a better product?

Apparently this is a risk SDL is not willing to take.

Best regards,
Bruce Campbell
ASAP Language Services

Unknown said:

Seems a strange question, given that I wrote " If you look at any international (recent) standard, the numbers will be in the format I just mentioned. It is a worldwide standard. Has been for quite a while." Everybody uses this standard. It was decided ages ago to completely ban thousands separators of anything other than a space. Either a comma or a dot can be used for decimal, but a dot is preferred. I'm flabbergasted that anyone in this industry wouldn't know this.

I guess what really matters here is what you want, and not what the standard is (whether this is what everyone uses or not).  Studio draws it's language settings from your computer operating system.  An example of the sort of thing this means would be here (this is actually out of date now and is only W7 but the settings have not changed much):

https://www.microsoft.com/resources/msdn/goglobal/default.mspx?submitted=0809&OS=Windows%207

Looking at Oracle we see something similar:

https://docs.oracle.com/cd/E19455-01/806-0169/overview-9/index.html

I don't know how old that is, but it's clear that it's still quite normal to handle numbers in this way.

One thing I would agree with Bruce on is that we should support a more flexible way to handle numbers.  I've wanted this for a long time, and this is because it doesn't matter at all what the standards are, it only matters what your client expects to see, and what you have been given in the source.  We're not here to judge the way documentation is put together.  But we don't have it right now so I'm trying to be honest and helpful with you so you can handle the task you have been given.  There's no point in me doing anything else.  That's why I wondered about your response.

In my opinion the best approach when faced with something like this is the following:

1. Let Studio do what it wants as long as the numbers are being transposed correctly (forget the formatting for now).  This way you get accuracy where it's most important and consistency
2. Once the job is complete run a search and replace on the numbers across your project using something like the sdlxliff toolkit which lets you tackle the whole project in one go
   https://multifarious.filkin.com/2017/01/14/revisiting-the-toolkit/

Then submit your idea, or vote for the ones already there.  The only way things will change is if enough people make their voice heard where it counts.

Unknown said:

Why do my replies seem to be going to different forums? This is weird. I reply here and the reply actually shows up somewhere else.

They just go to the end of the thread.  If you use the advanced editing options you can quote the text you are replying to and then it makes more sense.  Another example of using the tools they way they work and don't fight them... I'd like things to work in a different way too, so I ask this where it helps ( https://community.sdl.com/developers-more/feedback-groups/community-help/i/communityideas ) and make the most of what's here.

...and here is the idea to vote for: 

https://community.sdl.com/solutions/language/translationproductivity/translation-productivity-ideas/i/trados-studio-ideas/autolocalisation-of-numbers

Unknown said:

If you look at any international (recent) standard, the numbers will be in the format I just mentioned.

Examples? I read lot of various specifications and standards for last 15+ years, but have never ever seen it. Perhaps it was "widely adopted" only in a very narrow and specific area...

Unknown said:

It is a worldwide standard. Has been for quite a while.

It is my understanding of the Wikipedia and related articles that it exists as suggestion only and was actually not accepted due to various "compatibility issues", so to say... e.g. due to the required Unicode "tiny space" character (which is BTW NOT the "non-breaking space" you originally mentioned), which makes the entire concept not acceptable for usage in non-Unicode environments.

Unknown said:

...and here is the idea to vote for: 

https://community.sdl.com/solutions/language/translationproductivity/translation-productivity-ideas/i/trados-studio-ideas/autolocalisation-of-numbers

Exactly... and yet it only has 15 votes!  Considering how much noise these problems generate I'm amazed this isn't at the top of the list!