331–340 of 392 posts
Clearly there is some reason to do this. I mean, Google does it, and they employ some of the most brilliant people on the planet. Showing people their website in the wrong language is clearly losing them money, so minimizing that is a very direct way to increase profits. There must be some reason they rely on IP more than on Accept-Language. They don't leave money lying around, and there's no way Google engineers are…
Not accepting Accept-Language is one of my major pet peeves. What makes it worse is that many multilingual websites translate their language-switching buttons and the list of languages to the current language .... which is beyond fucking stupid and defeats the purpose. Wikipedia does this right. The button to switch languages is clear, using a universal multilanguage icon, and a list of languages (using the name of t…
https://www.mediawiki.org/wiki/Universal_Language_Selector/F...
Earlier quoted context omitted.
It's a circular dependency: how do you sort and list the locales or languages for someone to pick one, when by definition you don't know their locale yet? You have to either make some best-guess approximation (IP geo, browser headers, etc) or use a locale-invariant sort, both of which will be wrong in some cases.
can't you just sort all as int? the codepages usually come roughly sorted, and while no one knows which of 檎 or 橙 comes first, I don't think it'll be particularly offensive whichever way a random app did, to most.
I also hate the youtube "feature" that translates the titles of videos to your setting's language. This is so annoying. I can understand English and don't need these automatic translations.
About the translation, sure, "boot" ≈ "iniciar", "window" = "ventana", but for (microsoft) windows, and other names in foreign languages, the same name must be kept.
My biggest annoyance is with Google. They know who I am, they know I am traveling, they know my language preferences (English) and yet I still get language based on my location on certain pages. I let you track me Google, please use it for some good UX and not just advertising.
Indeed. Catalan speakers have Spanish forced down their throat no matter if Spanish has never been associated to the Google account in any way, nor in the system or browser language preferences. In my case, I live in the United States, but Google is determined to serve me Spanish results even for Catalan-related queries. E.g. preferring the Spanish Wikipedia. The search engine's behavior has had ups and downs over th…
I'm curious, what are the keywords that trigger that?
Earlier quoted context omitted.
> If you want to see bizarre sort rules, look up how french sorts accent characters. I tried to do this, but there do not appear to be any sources addressing this question. I did find a French Stack Exchange question asking for this exact information, and complaining that there are no sources (other than an uncited wikipedia page) that address it. There is no answer posted, but there is a comment from a French guy su…
Here is a blog post talking about it https://archives.miloush.net/michkap/archive/2004/12/31/3447... Or a more technical version at https://www.unicode.org/reports/tr10/#Backward Another case that is kind of weird is thai https://www.unicode.org/reports/tr10/#Rearrangement
I notice that post suggests that Académie française specifies that accents should be sorted in reverse, and includes a link over the words "Académie française", and yet that link doesn't go to a supporting document.
A while ago I complained on this forum that Amazon's hyphenation for Kindle ebooks is abysmally bad. (Which is still true.) Someone responded to say that the hyphenation algorithm for English requires this. I pointed out that the hyphenation algorithm for English is a lookup table; each word has its hyphenation defined in the table, and when you need to hyphenate a word, you look up the hyphenation points.
Another response linked me to a paper describing how this table can be stored as a set of rules that provide hyphenation points in arbitrary letter sequences rather than dictionary words. That paper is very clear about its goals; it is an advance in data compression, proposing a method of storing a lookup table that takes less space than the table does. It carefully goes over how to produce the ruleset from the table.
But somewhere along the line, people confused the data compression algorithm (of storing the lookup table as a ruleset) for the hyphenation algorithm. They will now tell you with a straight face that a single ruleset that seems to have gone around represents the hyphenation algorithm for English, even if the word you want to hyphenate wasn't in the table that that ruleset was prepared from. And this is false.
It looks to me like something similar has happened in English speakers' understanding of French sorting order. It's very easy to explain why the example quadruplet has the sorting order it does:
cote
côte
coté
côté
These four words have two pronunciations, and the pronunciations are grouped with each other. After that, "cote" comes first by virtue of bearing no accents, and "o" comes before "ô" for the same reason.
What's happening here is that although French generally pretends that "e" and "é" are the same letter, they aren't, which forces -e (not pronounced) to come before -é (pronounced!). "o" and "ô" actually are the same letter, and can be ordered flexibly.
The rule "sort the accents in reverse" arises as a coincidence; it happens to be the case that this distinction is most significant at the end of French words. But French speakers would reject this ordering:
cetot
cétot
cetôt
cétôt
Earlier quoted context omitted.
> in alphabetical order Well, it's in an order, but I don't know about alphabetical. I clicked on today's English featured article and looked at the languages: "中文", "Italiano" are "suggested", then the remainder are grouped by geographic region, and aren't particularly alphabetical. They appear to be in groups which are still not alphabetical. Europe seems to have a Cyrillic group but "Қазақша" is shown after "Украї…
Yes, that’s confusing and probably hard to find a good balance. Someone speaking Greek or Czech may expect to find their language around E (Ελληνικά) or C (Čeština), but nope, on Wiki it’s all the way after Z.
A reasonable approach might be to sort the list of names by using, as the sort keys, the strings projected through a Unicode normalization function, followed by folding to upper case. Then Čestina gets mapped to CESTINA and at least appears among the C's.
Much more importantly: Never ever auto-translate content to the user's language. Present what languages you actually have the data in. The user is smart enough to click the "translate" button in the web browser should they want. That translation is also likely to be better quality. English is not my first language. Or my second. But I understand it well enough to work in it every day. And I never ever want to wade th…
Earlier quoted context omitted.
I don't think Accept-Language supports "Translated", "Exact" or "Soft"? But yes, that would match the language setting that GGP asked for.
This is expressed as the quality parameter. To make the system GP proposed work atop HTTP content-negotiation, a server operator should assign a very small number to the automatically translated content.
(Also note that I wasn't talking about automatically translated content necessarily. Manually translated content still often is of worse quality than the original language.)