October 25, 2017 at 1:32 pm
Good developers make mistakes on simple things. This is one of those areas that we should have a system handle itself because the permutations of regional differences is crazy.
I'd like to ensure developers write high performing code and leave things like this to the system. And, of course, get MS to improve the performance of FORMAT() in future versions.
October 27, 2017 at 5:05 am
Jeff Moden - Wednesday, October 25, 2017 8:07 AMTomThomson - Wednesday, October 25, 2017 4:30 AMSteve Jones - SSC Editor - Tuesday, October 24, 2017 7:42 AMFORMAT is locale specific, which is what we typically want for functions. We don't want to depend on the developer accounting for regional differences.This returns values that are what the developer wants. If month and day are returned, that's what this does. If you display the year, no one at this point should be showing 17 for 2017. That doesn't seem like good design. However, if that's what your users get confused on, include the year in the function.
In my experience, applications' users want their formats, not the developer's preferred format . When a service supports lots of languages the developer has to write code to enforce the correct locale according to which language the particular end-user is working in. Often a service which is designed for a multi-lingual environment will have a contractual requirement to get things like date formats right, and the developer has to deliver that requirement.
Heh... and that's just for front-end stuff. Creating files to meet the specs of various external targets is a whole 'nuther pain in addition to the pain you mention. Considering the incredible slothfulness of FORMAT function, I'd have to be really hard pressed to ever use it.
None of our mulilingual stuff at Neos ever used the FORMAT function or the underlying .NET thing it's based on (probably because our creative director and his team had never heard of it, and I certainly wasn't going to tell anyone about it). As for the back end, that was comparatively straightforward - text held in all required languages (identified by a language ID), mostly in fairly small chunks (1 sentence or less) with place markers where variables (like date or time or price or tax rate or phone number or whatever) would be inserted after conversion to appropriate text format. The biggest problem was making the on-screen layout work successfully with the different lengths of the same text in different languages (orientation mostly didn't matter, almost all the languages we might have needed normally use just one orientation and are read by rows top to bottom with each row read either left to right - like English - or right to left - like Arabic). We decided no screens except the language selection screen would display more than one language at a time, and that greatly reduced the potential for excessive complexity.
Tom
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply