Recognizing commas as valid decimal separators

[JGD]

Hi guys!

 

I just stumbled into a little nag… I'm still using CS6 at my job, but gradients in both Ai and Ps are so crappy that for gradient layers in Ps I've decided to resort to AD instead.

 

The thing is, when copying measurements from Ai's Transform palette to its AD counterpart, the values use a comma separator (maybe that's not the default, but it's what we use in Portugal and, thus, the default separator in the Regional settings preference pane), which AD unfortunately doesn't recognise.

 

So… having to manually change the separator from a comma to a period instead of having AD recognize pasted values regardless of the standard used is a little nag, which adds up over time for people who may not adhere strictly to the period standard. Also, having AD's palette ignore duplicate unit names (like “mm mm”) and, thus, making it extra fool proof, would be terrific, but maybe that would entail too much code? I mean, the fact we can perform operations directly on the input fields, much like in Ai and ID, is great enough already.

 

Also, on a related note: AD's Transform palette rounded the values to a single decimal value… or did it? Isn't AD supposed to be more precise than Ai, with all those humoungous mega-zoom percentages and whatnot?

[Ben]

We haven't regionalised the app yet.  This will be something we look into when we do this.

[JGD]

Thanks, Ben!

 

But while I do appreciate the acknowledgement to my feedback, what timeframe are we looking at?

 

You see, this is more than a localization issue alone; it's more a matter of conforming to Apple's HIG and each user's own OS X settings for measurement units (in fact, if I wish, I may just go to the International prefpane and switch the decimal separator to a period – independently of all the other settings, while I'm at it –, but then I'd have to retrain my muscle memory and it would otherwise look weird – visual memory being harder still to retrain –, and for what?)… I've never used Adobe CS on my native language (because, in fact, it was never avaliable in european portuguese, but only on brazillian portuguese… Which, while being the same language, has such big vocabulary and grammar differences that using any pt-BR localized version of technical software becomes more annoying than helpful – and yes, while I might come off as, or even actually be, a bit pedantic about it, the difference between pt-PT and pt-BR is *way* bigger than between en-GB and en-US, trust me on that one –, and there's always the added ease of looking for community support/tutorials angle which might even preclude me from adopting a pt-PT version – unless I could toggle it on the fly either on AD's preferences or on the International prefpane, neither of which options were ever offered by Adobe's apps) but, yet, it always somewhat conformed (in its own quirky, convoluted, inconsistent and sometimes buggy way) to the HIG.

 

So, is there any chance that this may be fixed (because, in my eyes, it is indeed a bug/ommission and not an admissible “feature”) earlier and/or work regardless of the localization we are using (if any)? I could easily envision AD being ported to pt-BR waaaay ahead of pt-PT (if the latter ever comes to pass, at all), and wouldn't be too happy having to deal with nags like this because of that (with something apparently “big” like working, reading, writing, speaking and even thinking in english, I can live just fine, as you might have guessed by now; it's just these little things that get me :P ). Also, I might as well add that linguistics ≠ mathematical conventions and localization ≠ international/unit settings, as you've already acknowledged by, obviously, allowing users to choose imperial or metric units regardless of which side of the pond they're on. Or is that a too far fetched assumption? ;)

[Dale]

Although Portuguese might be some time off there is other localisation work happening as we speak JGD, so I reckon it won't be too long before this gets sorted by the devs, likely within Q1 2015.

 

It may well appear in a dev version sooner, check out the beta section of the forum.

[peter]

What does Rui have to say. This sounds like it's an area he knows well :ph34r:

[JGD]

What does Rui have to say. This sounds like it's an area he knows well :ph34r:

 

Since we're even from the same city, I am curious to read his take as well. ;)

[peter]

Since we're even from the same city, I am curious to read his take as well. ;)

Knock, knock.

[rui_mac]

About the localization of applications, personally, I was never very fond of them. I prefer to have everything in english because it is a much more efficient language, mainly with technical stuff.

Also, because some stuff is untranslatable to other languages. Or, when translated, becomes too long or ridiculous.

For example, "Text Wrap" would be accurately translated to portuguese as "Curandel" but I bet almost no one (even professionals) knows that word. So, it would have to be translated to something like "Repulsão de texto" ou "Adaptação de texto" and that is a bit ridiculous and it does not accurately describes what it does.

There are applications that, due to their specific "universe" are particularly hard to translate. For example, I started out translating Cinema 4D to portuguese and it proves extremely hard to translate some stuff: "Render" has no possible translation for portuguese, for example. Also, stuff like "Subsurface Scattering" or "Spline" or "Subpolygon Displacement" are particularly ridiculous, when translated. We end up with a mishmash of portuguese and english terms.

 

That being said, I understand that having an application in a native language is desirable for many people (people who have difficulties in english or are too lazy to try to learn technical terms). But, even if Affinity Designer gets a portuguese translation, I will go on using the english version ;)

 

As for the comma/period in the decimal numbers, it should accept both and don't even resort to the system localization settings for calculation. Internally, it should turn everything into a period for calculation purposes and only resort to the system localization settings for displaying.

[Ben]

As for the comma/period in the decimal numbers, it should accept both and don't even resort to the system localization settings for calculation. Internally, it should turn everything into a period for calculation purposes and only resort to the system localization settings for displaying.

 

Speaking as the guy who will probably end up coding this, I can't imagine what consistent logic you'd use to allow arbitrary use of commas and period symbols.  For example - without knowing which convention the user intended, what are these values:

 

1,234

1.234

 

It only makes sense if a value includes both symbols, giving you some clue which convention was intended.  For example,

 

12,345.678 901

 

The problem we have is that different locales use different delimeters for thousand groupings, hundreds groupings, decimal point, thousandth grouping etc.  Using space as a delimiter is a particular pain when it comes to parsing, as for all other tokens it would be regarded as a token separator.

[rui_mac]

I never met anyone who separated thousands from the hundreds using a comma. I guess that is just "old school" ;-)

When someone needs to type, lets say, the year we are in, it types:

 

2014

 

and not

 

2,014

 

So, I believe it is safe to assume that when a user types

 

2,014

 

it means 2 as integer and 0.014 as the decimal part.

[rui_mac]

So, just remove all spaces and turn all commas into periods. If the user used commas as delimiter for thousands and hundreds, it is just wasting his time (and keystrokes) as it is NOT required. It will learn soon that the comma is not required.
Specially if he/she types something like:

 

12,456.71

 

and it gets changed to

 

12456.71

 

as soon as he/she presses Enter.

Also, as soon as he/she types something like:

 

12,345

 

and it gets changed to

 

12.345

 

as soon as he/she presses Enter.

[Ben]

Unfortunately, those are not safe assumptions.  An example we've had is from someone who wants to copy and paste values from elsewhere.  Those values will be in whatever locale they use, and will include delimiters for the thousands.

 

So, they could quite easily paste 2,013 and mean 2013, not 2.013.

 

If we allow locales, they must be followed accurately.

[rui_mac]

Well, then add a preference checkmark to allow for system localization interpretation and plain, simple "number + period" interpretation ;)

When I'm coding, whenever I stumble on two or more possible ways of doing something in particular, I add a preference option :)

[Mr. Doodlezz]

Count me in about the comma thing, I find it very important for the workflow. Rui_mac gave reasonable examples why it should be considered.

 

Here's another point: this is what german Apple keyboards with numpad look like:

 

So personally I'm very used to commas as decimal separators, other tools on Mac can handle both input, see the calculator for instance I believe.

I never heard of any designer who enters thousands with extra separators in applications or calculations, often everything must be configured as quick as possible – personally I feel it’s just obstructive for the workflow.

It would be different if you're working as a copywriter where this kind of representation may appear in a price tag, headline or any other actual visible thing in the end product for client and customer.

 

The preference option would be the ideal solution for this feature I think.

[rui_mac]

Like MrDoodlez said:

 

"It would be different if you're working as a copywriter where this kind of representation may appear in a price tag, headline or any other actual visible thing in the end product for client and customer."

 

And, in those cases, the text would go into a text box, for design purposes, not into an edit field, for parameters.

[Andrew Tang]

This has already been implemented into both betas and so will be available in the next app store release. It will honour your system settings for decimal places.

[Mr. Doodlezz]

Oooh, I see! Nice and very appreciated, thanks for responding to us Andrew!  :lol:

[Esteban]

Just jumping in this old thread.

 

I thought it was in previous versions possible to use a comma as a decimal separator. But now (AD 1.5.4) I can only use period.

Is it a preference setting to use a comma as separator?

 

Thanks !

[Mr. Doodlezz]

Thanks, Esteban for recalling this thread.

 

I would also like to know why it's changed back to strictly using either comma or point for specific languages.

My preference is using the english UI, but working with a german keyboard layout using comma is much more convenient – this was already working at some point. In every language both inputs where handled correctly, one could enter comma or point with any language.

 

I already was writing to someone at Affinity via Facebook but couldn't find this thread to refer to.

Also not much information about the problem or its solution could be given.

 

This problem – again – is really bugging me out and I'm wondering why nobody else is talking about it.

 

Greetings

Dennis

[Fixx]

I can use either comma or point in AD/AP as in other apps too. Seems to me correct behaviour. Locale is Finnish, with English as language.

[Mr. Doodlezz]

I can use either comma or point in AD/AP as in other apps too. Seems to me correct behaviour. Locale is Finnish, with English as language.

 

Hey Fixx, I suppose you're using the latest versions of the apps as well?

This is odd, maybe I should consider moving to Finland in that case. ^_^

 

Greetings

Dennis

[Fixx]

OSX seems to autocorrect point to comma in all applications :-)

Basically you can set preferred decimal in Language & Region Preference, but it does not affect autocorrect.

[Esteban]

Strange… I thought before AD 1.4.2 it works entering a comma. So I don't know what's changed.

[JGD]

Unfortunately, those are not safe assumptions.  An example we've had is from someone who wants to copy and paste values from elsewhere.  Those values will be in whatever locale they use, and will include delimiters for the thousands.

 

So, they could quite easily paste 2,013 and mean 2013, not 2.013.

 

If we allow locales, they must be followed accurately.

 

I thought I should chime in again, too. Definitely either giving more refined options for parsing delimiters and separators or allowing the user to at least specify which assumptions Affinity apps should make (and, if possible, automatically honouring the macOS' regional settings) would still be the best course of action.

 

Also, think of it this way: besides the main user's muscle memory, most of the time that we will be copying and pasting values gathered from outside of the app those will, yes, either come from people from our own country, or from the macOS calculator app / Spotlight calculator results generated on our very own computers (yes, I am aware that Affinity apps allow, like Adobe apps, simple operations, but sometimes we need to calculate proportions with the rule of three, square roots, golden section, etc., or may just wish to perform and keep track of our calculations elsewhere – personally, I use plaintext files in TextEdit), which also honour said regional settings.

 

It's people on fringe/niche cases, like designers working abroad or with people from multiple countries that have to adapt and manually swap decimal separators and delimiters (or just remove the latter and have Affinity convert them to the appropriate, customised setting), and not us boring folks who don't collaborate that much with foreign colleagues (I actually have foreign clients, interestingly, but my cooperation with them doesn't go into that level of detail). ;)

[Macoun]

+1