Fighting back against proper noun feature names by Scott Kubie – The post highlights the issues of using proper nouns rather than common nouns ("My Account" vs "account"), and briefly mentions how localizing proper nouns can be difficult in other languages like German because of how nouns are capitalized.
Language Plural Rules from the Unicode Consortium – In languages like English and French, the pluralisation rules are often simple: "zero apples, one apple, two apples". But in other languages like Ukrainian it's more complicated: "0 яблука, 1 яблуко, 2 яблука, 5 яблук", where the suffixes are all different. This website is a reference for different pluralisation rules for several languages, including integer/fractional cardinals, ordinals (0th, 1st, 2nd, 3rd, 4th), and ranges (2-3 days).
Title-case is not a thing in German and Dutch – English uses title case for things like book names or headlines. German and Dutch does not. These capitalization conventions have implications for things like buttons and menus on websites and apps.
Apple's Human Interface Guidelines says "how you format your text is a reflection of your app’s voice. Title case is more formal, while sentence case is more casual. Choose a style that fits your app".
My personal recommendation is to not use title case for English to help avoid the issue of proper nouns in translations (see Fighting back against proper noun feature names), and instead use sentence case.
IsThisArabic.com – If you are handling Arabic text and don't know if the text is being rendered correctly, this website will help catch common errors. After that, visit NotArabic.com to apply what you've learned and spot the mistakes!
Apple Localization Terms Glossary – Apple has a decent list of translations for some common phrases used in their applications. This website, maintained by Kishikawa Katsumi, is a large list of localization strings that can be used as reference when creating your own app.
Unbabel Community Support: Language Guidelines – This website has a list of language guidelines for dozens of languages and regions. I'm unsure how reliable this reference is, but it gives a nice overview of some edge cases to consider, including grammar, orthography, formats, and other localization challenges. They also have a section on Linguistic tips.
Why You Should Not Parse Localized Strings by Shane F. Carr – The post lists several problems with parsing localized strings like dates and numbers, and making assumptions about the user's locale (Something that I've also written about in Locale vs language vs region). The post also has some suggestions on how to avoid parsing localized strings in the first place by using native input fields (Which I've also written about in Numeric input fields) and standard interchange formats.
Localization issues across countries
App developers that wish to add a weather display to their app may want to consider temperature ranges outside the area they live in. BasicAppleGuy discovered that Apple's StandBy Mode for iOS does not handle freezing temperature values, and converts temperatures like -29° to ellipsized numbers like -2…. Commenters speculate that the feature was only tested in Cupertino.
Google Maps UX: The India Conundrum by Elizabeth Laraki – In some countries, like India, many streets do not have a name. Before real-time GPS in phones became mainstream, generating turn-by-turn directions was a challenge, because without street names there were no assurances to the driver that they took the correct turn. In 2008, Olga Khroustaleva and Janet Cheung conducted field research in India and identified that people use landmarks in four ways: Orientation, description, confirmation, and error correction. From this research, Google Maps added landmarks to their turn-by-turn directions. This feature still exists in Google Maps in 2024, whereas competitors like Apple Maps, Bing Maps, Mapbox, and OSRM do not have this feature. However, since 2008, many drivers will have GPS in the vehicle to provide real-time feedback, so unnamed streets in turn-by-turn directions is less of an issue today. The primary use-case of this feature would be for printing out the instructions for offline use.
National conventions for writing telephone numbers vary by country – For example, in the United States, phone numbers are often written as: XXX-XXX-XXXX. In the United Kingdom, phone numbers are formatted as XXXXX-XXXXXX. Even within a country the formats can differ, like Poland where landline and mobile phone numbers are formatted XX-XXX-XX-XX and XXX-XXX-XXX respectively. This has implications for developers who wish to add placeholder values in forms, like in this example where developers from the US made the wrong assumptions about UK phone numbers. My recommendation is to avoid placeholders entirely. Also, input masks should also be avoided.