I want to create dynamic text in a layout calculated from an attribute value and I need it to use the German way to format numbers (i.e. comma for decimal places and dot as thousands separator).
When I use just the field value I can check the 'Thousands separators' option and ArcGIS Pro honours the system language settings (I presume).
But when I use an expression that option is not available. And using the text function in Arcade with number formatting creates the English format.
Here is an example:
Is there a way to create an Arcade text/label using German number formatting (or other non-English formats)? I'll probably need this more often, not only in layout text but also for labels or annotations.
I know I could create a new attribute field, but I want to avoid that, as it would produce lots of redundant data over time.
(I'm currently using ArcGIS Pro 2.6.1 with English UI, system language is German)
Solved! Go to Solution.
You'll have to do it manually:
var value = 1234567890 / 1000
var x = Text(value, "#,###.0")
var pat_rep = [[".", ";"], [",", "."], [";", ","]]
for (var i in pat_rep) {
x = Replace(x, pat_rep[i][0], pat_rep[i][1])
}
return x + " kt"
// 1.234.567,9 kt
You'll have to do it manually:
var value = 1234567890 / 1000
var x = Text(value, "#,###.0")
var pat_rep = [[".", ";"], [",", "."], [";", ","]]
for (var i in pat_rep) {
x = Replace(x, pat_rep[i][0], pat_rep[i][1])
}
return x + " kt"
// 1.234.567,9 kt
Thank you, Johannes. So it's basically replacing "," with "." and vice versa using ";" as a place holder? Seems like an awful lot of calculating for such a simple thing. I hope it won't affect performance too much when used in labels. But it'll do for the layout and I like the for-loop (much more elegant than writing replace again and again like I would have 😉 ).
Yes, that's exactly what the code does. Performance should be OK, this is a simple operation, as opposed to e.g. intersecting another layer or filtering a table.
Although the loop makes the code more flexible, in this case writing the 3 Replace statements might be better (less code and fewer computations), but you wouldn't notice any performance difference.
If my answer was what you were looking for, please mark it as solution, so that your question shows up as solved.