>Some languages have complex agreement between parts of the sentence, e.g. where gender of the verb must match the subject.
English is one of these, in some cases. E.g. "cats chase mice" while "my cat chases mice". IIRC there are similar whole-sentence complications with tense too, but my brain isn't caffeinated enough to think of them at the moment.
That's rather simple agreement. The languages I know of are compatible with that. They either have a similar or simpler number agreement, at least for the third person. English has better examples, e.g. a vs an. If you template some text, you need to write agreement rules for that: "Are you interested in [a/an] {product}?"
A great example I just saw was when I was reviewing a PR with translations into one of the Slavic languages that does Slavic plurals and it just avoided the problem by translating the sentence as "the number of things: {number}" whereas in other languages it was "{number} things". Genius, frankly.
Slavic plurals (not in every Slavic language don't quote me):
- when the name of the number ends with "one" you put the noun in the singular. So numbers like 1 and 21 and 100001 use singular nouns, but not 11 because its number is not "ten-one"
- When the name of the number ends with "two" through "four" you put the noun in the genitive singular so you say "I have two of chicken." Again, the teens don't fit because they aren't formed by "ten-two" etc.
- Otherwise: genitive plural "I have five of chickens."
> Title case or headline case is a style of capitalization used for rendering the titles of published works or works of art in English. When using title case, all words are capitalized, except for minor words (typically articles, short prepositions, and some conjunctions) that are not the first or last word of the title. ...
> The rules of title case are not universally standardized.
Back when I was making WIN32 apps (that at the time didn't have a layout manager), the hardest languages to localize for were:
* German, simply because the German translations we were using were twice as long. I don't speak German so I couldn't judge if all those extra words were required.
* Simplified Chinese, because the default font in that language was huge - single characters would take twice the width (and more irritatingly, height) of an English character.
* Japanese, partly because the default font was also large but mostly because the multibyte character codes (this was before unicode support) for common words included bytes that were commonly used for separators in other languages. So things like backslash path seperators (which Japan didn't use) would have to be handled with extreme care in the code.
In german words are often concanated resulting in words like Bodenseeschifferpatent(an license to drive boats with an bigger motor or an bigger sail). When you localise something german is easily one of the longest translations,
Pretty much the only thing I could find in the whole list that I thought anyone might believe is "every language has words for yes and no". But here's another myth that I find it hard to understand how anyone could believe: "interface design decisions are generally made by programmers". If a site uses country flags to indicate languages, it probably wasn't a coder that decided to do that, and whoever did make the call didn;t believe there was a one-to-one relationship between countries and languages. I particular, pretty much everyone can think of at least one country other than the USA where they speak English.
I live in Poland and speak Polish but tend to have my devices set to English because of how low quality UI translations tend to be. The endless confusion this causes to software is amusing. Worst/best of all is Google Maps on Android, in which random parts of the interface, including voice directions, can independently be in Polish or English, and which is which changes on its own on a daily basis.
Windows is notorious for this---its code page (i.e. character encoding and thus effectively language and script) is directly tied to the locale. Most importantly this meant the same code page 950 (Big5) was used for both Taiwan and Hong Kong. Hong Kong had its own extension to Big5 called HKSCS, so they could be distinguished only by the OS edition. (Internally Big5+HKSCS has a separate code page 951, but AFAIK this wasn't exposed publicly.)
"Ordering of words follows simply from ordering on the letters in the alphabet" - nope, Spanish "ll" is not in the alphabet and is sorted like a single special letter.
"It's always lexicographical left to right or at least lexicographical in a single, consistent direction?" - nope, accents in French (è,é) are compared right-to-left.
Native speaker of Spanish here (from Spain, living in Chile). “Ll” is sorted as two independent letters, same as “Ch”.
Until 2010, the Real Academia Española (along the other Academias, of the various countries that speak spanish), considered both “Ll” and “Ch” distinct letters of the alphabet, and they were sorted accordingly [0][1][2].
I was JUST making a demo showing that sorting is different per locale (using String.prototype.localeCompare() in JS) and I was SHOCKED that Spanish no longer orders things "langosta, lugar, llama" but rather "langosta, llama, lugar." I had to redo things to do German vs Swedish sorting (In German, ä comes between a and b, whereas in Swedish it comes after z). So here I was thinking that the browsers were sorting naively, but in fact they are more with the times than I am.
Good list, but I imagine most programmers don't believe most of these falsehoods and are aware of a lot of these issues.
It's just not always easy to deal with them correctly - and quicker/easier/cheaper to just do the thing that will be right for the large majority of your users.
If you want to create a good piece of software (let's say Photoshop) in English, create it in English. If you want to create a good Photoshop in German, create it again but in German. You can use the English one as a base, but treat it as a new product that happens to have a lot of code reuse, not a variant of English Photoshop.
Then, to reduce maintenance costs, you can fold the changes back in to the original software, using conditional statements and so on. This creates International Photoshop, of which English Photoshop, German Photoshop and Chinese Photoshop are just configuration options.
What you should not do is create International Photoshop first, and then specialize it for English and German and Chinese. You'll find places where the localizations don't fit into the framework you created, and then you'll either go back and change the framework, or (more likely) you'll just use English conventions in the non-English versions to make them fit the framework, and people in other countries will just live with with their language's equivalent of Engrish.
This is related to "a library must have 3 clients", "make a game not a game engine", etc, also "red green refactor". You have to make several specific things before you can generalize anything. If you don't make the concrete things first, you don't know what has to be generalized and how, and what doesn't. When you make the framework first, it has all the wrong generalization points.
Of course, if you already did this for a previous project so you already know how the framework should be, then you can try the framework-first approach. But beware - with that approach you might get stuck in the second system effect.
This comment has been delayed for hours by HN's rate limit.
Another one: depending on the language, 0 is either singular or plural. In French it's singular and it's always fun to see the denial in the eyes of my French colleagues when I tell them that 0 is plural in English.
28 comments
[ 241 ms ] story [ 1611 ms ] thread- Sentences in all languages can be templated as easily as in English: {user} is in {location} etc.
Some languages have complex agreement between parts of the sentence, e.g. where gender of the verb must match the subject.
- For every lower-case character, there is exactly one (language-independent) upper-case character, and vice versa.
Dutch capitalizes ijzer as IJzer.
- The lower-case/upper-case distinction exists in all languages.
Plenty of languages without: Hebrew/Arabic, “Chinese”. Japanese doesn’t even have spaces.
- All languages (that use the Latin alphabet) have the same alphabetical sorting order.
Spanish has ll, ch and rr in between k/m, c/d and q/s respectively.
Neither google nor microsoft swift keyboard know that İt's is not the same thing as It's.
(It's interesting, because when computers were finaly powerful enough to remember all the weird cases, we dropped them.)
English is one of these, in some cases. E.g. "cats chase mice" while "my cat chases mice". IIRC there are similar whole-sentence complications with tense too, but my brain isn't caffeinated enough to think of them at the moment.
Slavic plurals (not in every Slavic language don't quote me):
- when the name of the number ends with "one" you put the noun in the singular. So numbers like 1 and 21 and 100001 use singular nouns, but not 11 because its number is not "ten-one"
- When the name of the number ends with "two" through "four" you put the noun in the genitive singular so you say "I have two of chicken." Again, the teens don't fit because they aren't formed by "ten-two" etc.
- Otherwise: genitive plural "I have five of chickens."
> Title case or headline case is a style of capitalization used for rendering the titles of published works or works of art in English. When using title case, all words are capitalized, except for minor words (typically articles, short prepositions, and some conjunctions) that are not the first or last word of the title. ...
> The rules of title case are not universally standardized.
* German, simply because the German translations we were using were twice as long. I don't speak German so I couldn't judge if all those extra words were required.
* Simplified Chinese, because the default font in that language was huge - single characters would take twice the width (and more irritatingly, height) of an English character.
* Japanese, partly because the default font was also large but mostly because the multibyte character codes (this was before unicode support) for common words included bytes that were commonly used for separators in other languages. So things like backslash path seperators (which Japan didn't use) would have to be handled with extreme care in the code.
I remember having to design dialogs with lots of empty space to accommodate the German translation.
So, SO many websites get this completely wrong.
"Ordering of words follows simply from ordering on the letters in the alphabet" - nope, Spanish "ll" is not in the alphabet and is sorted like a single special letter.
"It's always lexicographical left to right or at least lexicographical in a single, consistent direction?" - nope, accents in French (è,é) are compared right-to-left.
Until 2010, the Real Academia Española (along the other Academias, of the various countries that speak spanish), considered both “Ll” and “Ch” distinct letters of the alphabet, and they were sorted accordingly [0][1][2].
[0] https://www.rae.es/dpd/abecedario (in Spanish)
[1] https://www.rae.es/dpd/ll (in Spanish)
[2] https://www.rae.es/dpd/ch (in Spanish)
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
It's just not always easy to deal with them correctly - and quicker/easier/cheaper to just do the thing that will be right for the large majority of your users.
Then, to reduce maintenance costs, you can fold the changes back in to the original software, using conditional statements and so on. This creates International Photoshop, of which English Photoshop, German Photoshop and Chinese Photoshop are just configuration options.
What you should not do is create International Photoshop first, and then specialize it for English and German and Chinese. You'll find places where the localizations don't fit into the framework you created, and then you'll either go back and change the framework, or (more likely) you'll just use English conventions in the non-English versions to make them fit the framework, and people in other countries will just live with with their language's equivalent of Engrish.
This is related to "a library must have 3 clients", "make a game not a game engine", etc, also "red green refactor". You have to make several specific things before you can generalize anything. If you don't make the concrete things first, you don't know what has to be generalized and how, and what doesn't. When you make the framework first, it has all the wrong generalization points.
Of course, if you already did this for a previous project so you already know how the framework should be, then you can try the framework-first approach. But beware - with that approach you might get stuck in the second system effect.
This comment has been delayed for hours by HN's rate limit.
Changing case of a word can be performed by changing case of each letter individually.