Live data from Hacker News

A Localization Horror Story: It Could Happen to You

search.cpan.org

231–240 of 257 posts

Re: A Localization Horror Story: It Could Happen to You

#231

When I was in Japan I did proof reading for a Japanese feature phone. A major Japanese brand, actually. That was really comical. There was an Australian guy for English, an German guy, an Italian lady, and me for French. What they did prior to the meeting is: * translate from Japanese to English by Japanese people with a poor English level (maybe the software engineers actually) * translate from weird English to othe…

@eloisant: I work in automotive where I deal with translations for automotive clusters for one of the largest auto makers. Automotive companies are going to what are called reconfigurables which is basically an instrument cluster with no mechanical gauges; just a screen with gauges rendered by 3D engine. Center stacks too. I kid you not, the way we translate is to use Google translate as a first pass and then the scr…

> Another pain point is that we have a certain space where text needs to be displayed and everything is fitted using English but after translating to other languages, some strings are much longer than the allotted space.

As a rule of thumb, if you're using English strings to design your UI, you should account for 30% more space so other languages can fit in. Of course, sometimes this might not be enough.

Re: A Localization Horror Story: It Could Happen to You

#232
post #183
post #125

Earlier quoted context omitted.

Could also be from German, although this would also be written ne instead of neh. People from the northern part of Germany use this in pretty much the same way it is used in Japanese (at least according to what I know with my limited knowledge of Japanese) I always thought of this as a strange quirk that the same language construct can evolve in two unrelated languages. It's just like parallel evolution in biology.

Interestingly, there's also the Yiddish: nu? Which itself likely comes from German or Russian

That's also used in (and often a reference when making fun of..) the dialect in Saxony.

Re: A Localization Horror Story: It Could Happen to You

#234
post #105
post #69

I wonder if it isn't better to generate the messages as an AST, and have a language generator, the back-end of a compiler really, that generates strings for each language. I'm sure there will be less edge cases that way. /edit: wow, downvotes.

This compiles to "He likes 2 green cats" in English. The representation makes no assumption of SVO order, the grammatical category of numbers, and what cases and tenses are available. (OPRESENT ((OSUBJECT (OPRONOUN (3, 0))) ((OVERB, "like") OMUL (2, (OCAST (OATTR (OCOLOR "brown")), (ONOUN (OANIMAL, "cat"))))))) I'm sure someone smart will tell me what assumption I made that's invalid in some language I do not know, b…

Well, obviously, you're missing the mood.

Besides, I see two issues with that:

- While it may be more machine-readable, it's absolutely not human readable

- Something like (OPRONOUN (3, 0)) assumes that pronouns work like in English. Want to represent text in a language for which it is not the case with this system? No dice.

In short, I'd rather have an improved gettext (without hacks to detect if you're gettext'ing printf'd text...) than your proposed AST solution.

Re: A Localization Horror Story: It Could Happen to You

#235
post #202
post #124

Earlier quoted context omitted.

Upper and lower casing can't be assumed to be inverse; there are plenty of other cases where they will change (e.g. precomposed characters that don't have a precomposed upper case). The correct lower-casing of "I" in English is definitely "i"; the correct upper-casing of "ı" in English is maybe a wrong question, because it just isn't an English letter, so I guess you could argue for leaving it unchanged, but converti…

With Unicode, why aren't the two Turkish Is just treated as if they have nothing to do with the normal Latin I? The fact that the glyph for uppercase dotless I resembles the glyph for uppercase Latin I should be irrelevant, surely. It's a kind of typographic false friend situation. Maybe there's a missing level of indirection in Unicode that prevents it from doing this, but I can't see how there could be.

One answer is that unicode had to import existing documents; I suspect that a lot of documents are written in a Turkish codepage that would have been an 8-bit encoding with the lower half as ASCII, that wouldn't have bothered with a different codepoint for "Turkish" I. As I said, you can't rely on upper/lowercasing roundtripping correctly in general.

(I was about to give the example of ß, which is usually uppercased to SS. But interestingly Unicode has now adopted a codepoint for the (disputed, and currently lacking a typographic consensus) capital version, ẞ. So maybe a codepoint for "uppercase Turkish I" is on the way. Turkish users will still expect to be able to lowercase "I" to a dotless lowercase i though, since a lot of existing documents will have "I"s in)

Re: A Localization Horror Story: It Could Happen to You

#236
post #13
post #7

Slightly OT, mi favourite localization error was in Ubuntu when they had that nice netbook interface (that later would become Unity). The network icon label was "Rojo" in the Spanish localization, that is the word for "red" color. What? Well, if you translate "Net" to Spanish you get "Red"; and if you translate that again (by mistake), you get "Rojo". There you are :)

OT means Out of Topic? In french we say HS (for Hors Sujet).

HS may also mean Hors Service (Out-of-order)

Re: A Localization Horror Story: It Could Happen to You

#237
People here are talking about complicated, difficult solutions, like using a library to create text in multiple languages from an AST(!)

I think the moral of the post is simple: don't try to generate natural language. It won't sound natural. Just keep it basic.

"Directories scanned: %d" "Directories matched: %d" "Files matched: %d"

...will localize just fine

Re: A Localization Horror Story: It Could Happen to You

#238

Earlier quoted context omitted.

That's an error only an amateur translator would make. Guess who makes free software translations... A professional translator makes sure to check the context of the translation, it doesn't go blindly translating sentences and words without context.

> A professional translator makes sure to check the context of the translation, it doesn't go blindly translating sentences and words without context. 1. professional translators are human and make mistakes 2. context may not be available for third-party translators working on e.g. unreleased software strings (see currently top comment by "eloisant")

Somewhat relevant given the topic, don't read "it" at not-human.

Not everyone here speaks English as a first language and translating a non-gendered/unknown pronoun to English may result in "it".

Re: A Localization Horror Story: It Could Happen to You

#239

People here are talking about complicated, difficult solutions, like using a library to create text in multiple languages from an AST(!) I think the moral of the post is simple: don't try to generate natural language. It won't sound natural. Just keep it basic. "Directories scanned: %d" "Directories matched: %d" "Files matched: %d" ...will localize just fine

That might be ok for technical people who are used to this kind of "machine speak", but for end users it's often not acceptable. Consider the difference between:

    Purchased credits: %d.
    Remaining credits: %d.
    Buy more : 5 [link] / 10 [link] / 20 [link].
and

   You have purchased a total of %d credits and have used %d of them so far. You can buy [drowdownlist] additional credits by clicking here [link].
Which one do you think will have the highest conversion rate?

Re: A Localization Horror Story: It Could Happen to You

#240
post #235
post #202

Earlier quoted context omitted.

With Unicode, why aren't the two Turkish Is just treated as if they have nothing to do with the normal Latin I? The fact that the glyph for uppercase dotless I resembles the glyph for uppercase Latin I should be irrelevant, surely. It's a kind of typographic false friend situation. Maybe there's a missing level of indirection in Unicode that prevents it from doing this, but I can't see how there could be.

One answer is that unicode had to import existing documents; I suspect that a lot of documents are written in a Turkish codepage that would have been an 8-bit encoding with the lower half as ASCII, that wouldn't have bothered with a different codepoint for "Turkish" I. As I said, you can't rely on upper/lowercasing roundtripping correctly in general. (I was about to give the example of ß, which is usually uppercased…

I did a bit of research on this and you're right, legacy encodings are one problem. More seriously there seems to be no established way to manage multilingual text which includes homoglyphs (say by using colour coding) so you would really be replacing one problem with another.

It does seem like this Turkish I problem is the most conspicuous situation, maybe unique, where changing locale changes the behaviour of toupper/tolower. Unicode, on the other hand, has many homoglyphs and duplicate characters which all need to be dealt with.

http://en.m.wikipedia.org/wiki/Homoglyph http://en.m.wikipedia.org/wiki/Duplicate_characters_in_Unico...

Post reply on HN