I'm very new to the process of internationalization, so hopefully the answers to these questions aren't stupidly obvious.
In my app, I have some user-facing numbers that have no qualifiers or separators (i.e. they don't represent currency, time, or anything else; they're just numbers. And, I want, for example, 1000 to display as 1000, not 1,000 or 1.000). My questions as as follows:
If I choose to use a NumberFormatter to internationalize these numbers, what changes (if any) might it make to the format to the resulting String based on the user's locale? For example, would a right-to-left locale reverse the order of the digits in a multi-digit number?
My app's functionality depends on the user seeing all numbers in base 10 and each number 0-9 being representable as a single character... would internationalizing the numbers invalidate these assumptions?
For the record, this is the only code I'm using to try to internationalize the numbers:
NumberFormatter.localizedString(from: number as NSNumber, number: .none)
If you're used Cocoa for a while you're probably familiar with NSDateFormatter
and NSNumberFormatter. They're handy for creating formatted display strings from dates and numbers, or for converting date or number strings into numeric values, while supporting different languages and locales.
A few weeks ago I stumbled on NSDateComponentsFormatter, which lets you create formatted time intervals like "4 hours, 37 minutes and 17 seconds." Pretty cool.
There's also the related NSDateIntervalFormatter, which creates strings by comparing 2 dates.
Then there are some REALLY obscure NSFormatter subclasses:
NSMassFormatter
NSByteCountFormatter
NSLengthFormatter
NSEnergyFormatter
NSPersonNameComponentsFormatter
EDIT:
From the comments, I've aded NSPersonNameComponentsFormatter.
Searching on "NS*Formatter" in the Xcode help system reveals most of these, but not all. (It looks like the help text has to be indexed correctly in order for searching to work, which is annoying.)
That brings the total I have been able to find to
NSDateIntervalFormatter -Difference between 2 dates
NSDateComponentsFormatter -NSDateComponents to/from string
NSDateFormatter -Formats NSDates as strings
NSNumberFormatter -Formats numbers as strings
NSMassFormatter -Formats mass quantity as strings
NSByteCountFormatter -Formats byte counts in K, MB, GB, etc.
NSLengthFormatter -Formats length values
NSEnergyFormatter -Displays energy qualities in Joules or Calories
NSPersonNameComponentsFormatter - displays localized formatted names
Annoyingly, it looks like many of these formatters don't have a locale property, so it's not very easy to use them to create formatted strings in languages/locales other than the system's default locale. If I'm missing something, please tell me.
Does anybody else know of other formatters I'm missing? These are pretty obscure, but could save you a lot of time if you were to need them.
EDIT #2:
Question part 2: Is there a way to get output from the formatters that lack a locale property in locale's other than the system default locale? It seems silly that they don't ALL have and honor a locale property. It's pretty common to need to generate output for languages/locales other than the current locale.
There's no need to search. The NSFormatter documentation lists all of its subclasses. Look at the top of the page, in the "inherits from" block.
Note that this information is not available in the Xcode 7.3 doc reader. It's only available in the online docs (or by using the excellent Dash reader).
I went into
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks
and then did
for header in **/*.h; do ack -o 'NSFormatter' "$header"; done
which gave me some interesting ones:
NSPersonNameComponentsFormatter
CNContactFormatter
CNPostalAddressFormatter
DRMSFFormatter
MKDistanceFormatter
Doing the same for iPhoneOS.sdk didn't turn up any new NSFormatter subclasses.
I have two questions about decimals on my calculator-app:
(1)How do I add a decimal button?
(2)If I type or calculate a big number on the calculator it shows this:
https://www.dropbox.com/s/nuigto6vcok8rtk/Screen%20Shot%202013-10-12%20at%2016.22.44.png
Code: https://www.dropbox.com/sh/zu6ijmbvredssoo/2cH4rzDd3E
The calculator works with buttons
Im using xcode 5
Your post is far too vague. Does your calculator app use an iOS keyboard, or do you have custom buttons? And what do you mean a "decimal button"? You want a button that inserts a decimal place in the number the user is typing?
How you do that depends on how your calculator app works.
I'm not going to download and examine your app for you - sorry. You need to provide a brief, complete explanation of how your app works now, and what you are trying having trouble doing.
As for the output, that's scientific notation, and is a quite common way to display large numbers. The "%g" (or "%G") format string switches to scientific notation automatically if the exponent is large or small enough. Read the description of "%g" in the section of the Xcode docs on "Format Specifiers" for more information.
You probably want to create a custom NSNumberFormatter and use that to format your output number. That will give you more control than you get with stringWithFormat and the like.
This seems like a stupid question. Is the number "10" refered to "10" in Hebrew, Arabic, and all languages? I'm not seeing anywhere where it says you need to do anything special with numbers when dealing with localization. Maybe number format but what about the number itself? I would think that numbers would read differently in right-to-left languages but translate.google.com is giving me the same number back. Can anyone confirm this?
Arabic and Japanese (?) do have different glyphs for numbers, but the standard system is so commonplace, that usually numbers are not converted.
If you're using the .NET formatting functions, then the numbers will be formatted according to the system preferences (I'm talking commas and decimal points here)
Different languages can use different digit sigils;
Number representation is different. eg 1,234.56 in English is represented as 1.234'56 in German.
So the answer is yes.
The digits 0-9 usually don't require any localization, except minor tweaks like AndreyT said, but those are more "fonts" related than anything.
The only important thing to take into account is large number representation.
For example, take 1mio$
In Switzerland, it will be:
$1'000'000.-
in US
$1,000,000
In Japan it will be
$100万
I don't know other place, but you got the idea.
For Japan, it's very uncommon to see numbers greater than 10'000 without using a kanji.
But I think you should see with the person doing the localization.
For the actual numbers themselves (and not floating poing, thousands seperator, etc) there are in fact differences between languages.
Hebrew numerals actually use the Hebrew letters as a number system, though it is used only for "traditional" numbers, such as the year in the Jewish calendar, the chapter, verse and page numbers in the Hebrew Bible, in lists (similar to using roman numerals instead of numbers), etc. But for all other cases, Hindu-Arabic numerals are used (e.g. 1, 2, 3, 4...) and are written left-to-right, even while the rest of the Hebrew text is written right-to-left (i.e. NML KJIHG 123 FEDC BA).
In Arabic, most countries use the Arabic-Indic numerals, but the Hindu-Arabic numerals are also understood.
In any case, .NET localization should take care of all conversions and display issues, and there's nothing special you need to do unless you render your own GUI.
There quite a few tings that can be localized in numbers. For example, in USA the fractional part of a number (if it has a fractional part) is separated by a dot, while in Russia a comma is normally used. In USA commas would be used to separate three-digit groups in the number, while in Russia it is not customary to separate them at all, or space is used for that purpose (or maybe some other character, but not a comma). And so on (although most of the formatting options apply to monetary quantities).
Even the preferred way to write characters themselves can depend on locale. In USA the character for '7' is usually written in two strokes, while in Europe it quite often has a third stroke - a short horizontal line through the middle. This, of course, is less important, since the two-stroke version is still recognized everywhere.
If you are displaying the numbers for math purposes (for example, showing 5 + 3 = 8), then use the standard digits 0-9. These are used nearly universally in mathematics.
If you are displaying something that is highly localized
(i.e. pricing on a street vendor's point-of-sale system in Saudi Arabia), there are a handful of countries that use different digits that are localized to their respective languages.
Most regions of people in the world will be fine with understanding 0-9 though.
I found this website to be a good starting guide: https://phrase.com/blog/posts/number-localization/
Some examples:
Bengali, for example, uses the Bengali–Assamese numeral system, whose
digits differ from the Western Arabic system: ০, ১, ২, ৩, ৪, ৫, ৬, ৭,
৮, ৯.
In some locales like Saudi Arabia, for example, it’s common to
represent numbers in the local numeral system, Eastern Arabic, and not
the Western Arabic system.
Keep in mind that we are just talking about digits here. When it comes to fractions (/), decimals (.), percentages (%), large number separators (,), number symbols (#), etc. most regions have specific rules and that's a whole other topic. They are not universal.
When thinking about what areas should be taken into account for a localized version of an application a number of things pop up right away:
Text display
Date and time
Units
Numbers and decimals
User input formats
LeftToRight support
Dialog and control sizes
Are there other things/areas to remember or keep in mind when building a localizable application? Are there any resources out there which provide a listing of best practices not just for text localization but for all things around localization?
After Kudzu's talk about l10N I left the room with way more questions then I had before and none of my old questions answered. But it gave me something to think about and brought the message "depends on how far you can/want to go" accross.
Translate text bodies with aforementioned things
Test all your controls for length/alignment in LTR/RTL, TTB(TopToBottom) BTT and all it's combinations.
Look out for special characters and encodings
Look out for combinations of different alignments (LTR, RTL, TTB, BTT) and how they effect punctuation and quotation signs.
Align controls according to text alignment (Hebrew Win has its start menu at the right
Take string lengths into account. They can overflow in other languages.
Put labels at the correct side of icons (LTR, TTB etc)
Translate language selection controls
No texts in images (can't be translated)
Translate EVERYTHING (headers, logos, some languages use different brand names, product names etc)
Does the region have a 24:00 or a 00:00 (changes the AM/PM that goes with it too)
Does the region use AM/PM or the 24:00 system
What calendar system are they using
What digit is for what part of the date (day, month, year in all its combinations)
Try to avoid "copying [number] files" equivalents. Some regions have different rules about changing words according to quantities. (This is an extremely complicated topic that I will elaborate on if desired)
Translate sentences, not words. Syntax rules are too complicated to put in your business logic.
Don't use flags for regions. Languages != countries
Consider what languages / dialects you can support (e.g. India has a gazillion of languages)
Encoding
Cultural rules (some western images displaying business woman can be near offensive in some other cultures)
Look out for language generalizations (e.g. boot(UK) != boot(US))
Those are the ones from the top of my head. The list just went on and on...
Don't forget the overhead of converting all documentation and help files.
a couple hints from my J2ME apps days:
don't translate separate words, translate whole phrases, even if there are matching repetitions. You'll later have to translate to a language where words have to be modified differently in different contexts and you may end up with an analog of "color: greenish"
Right2Lelf includes numbering of lists, alignment, and alternative scroll bars
Arabic languages write the same letter differently based on surrounding letters. You can't just print a string from a character buffer, you'll need a special control to output those or support from you platform
alphabetical sorting is HARD. No native Chinese could ever explain me the rules, but they will always spot wrongly sorted words. There appear to be a number of options to sort Chinese. I guess other languages may have the same problem