Hacker News new | ask | show | jobs
by junon 1762 days ago
Correct. The grouping matters, and double-digits in groupings are also reversed - "fünf und sechzig tausend fünf hundert sechs und dreißig".

Another thing, years in German aren't spoken as "twenty twenty-one" as we commonly do in English, but instead the number is spoken out fully - "two-thousand one and twenty" ("zwei tausend eins und zwanzig").

2 comments

In England, the little voice in Google Maps told me to take the "B one thousand, one hundred and thirteen", when every human i know would call that road the "B one one one three".
I would honestly most likely say "triple-one three"!

IME road number† pronunciation in England goes out of its way to avoid "thousand" and "hundred" – with exceptions, of course. Off the top of my head, I reckon I say them like this:

* one or two digits = spoken as the number rather than the digits: A three, M twenty five, etc.

* three digits = sometimes spoken as digits: A two-one-seven - but sometimes broken into two numbers: B one-eleven

* four digits = sometimes the number A thirty-one-hundred (never three-thousand-one-hundred!), sometimes digits B triple-one three, sometimes year-style B thirteen eighteen

There are probably more variations that I can't think of right now too. It's a mess :D

† and bus route numbers, for that matter

In French, it’s faster to say « Cent treize » than « Un, Un, Trois ». Phone numbers in my country are grouped by two.
This is now totally off-topic, but I'd like to know if there is any Googler at all working on adding location tags to their text-to-speech model.

Hearing Google Assistant/Maps mispronounce German street or city names in an American accent is very grating to the ears. The pronunciation of a location name should ignore the language spoken, right? (Ignore for a moment the edge cases, like München vs Munich... although the voice says, "Munchin'," which is wrong in both languages!) And it can't be too complicated to borrow phonemes from another language where they don't exist... Right? Your American text-to-speech algorithm encounters an umlaut, then generate the correct waveforms from a language with umlauts.

(I'm sure someone reading this is jumping up and down, yelling about the "photo of a bird" xkcd.)

Not really comparable to photo of a bird, because using the geographic bounds for what language spoken there should work in 99.99% of the cases.

(I have my phone set to english, because I prefer it like that, despite living in austria, europe. Street names are one of the reasons I rarely ever use google maps for navigation)

It's a hard problem in a way. If my language is localized to English, am I more likely to understand the native pronunciation of a street, or the English mispronunciation?
That's true. To extend this idea, should you pronounce someone's name as they pronounce it? Even if you've only known it one way?

(The German Michael is kinda... Michh-aye-ehl'.)

I don't understand if you're presenting this question broadly, in a vacuum? Or if you're still in the context of your question about (mis-)pronunciation of streets etc. while providing navigation for a driver whose chosen language is not the same language as the current location, and who it may be safe to assume cannot understand the local languages' pronunciation even when the alphabet is similar (e.g. an English speaker in a Portuguese speaking country is very unlikely to understand if the navigayor natively pronounces "rua da Heitor do Rio do Engenho", a name I just made up that may exist somewhere, which I think demonstrates the difficulty I'm talking about.)
For map information, the map app might better tag the language of the word being sent to the TTS engine.
Ah right. My mistake. It would be five and sixty thousand ... Yuck!

I guess this is exactly what we're talking about---mistakes because you are not natively familiar with a particular system, and then you miss the non-base case. For me, I got the tens digit right but not the ten thousands digit.

In the memory case, it's knowing to change a pointer location because an address to a 32-bit value will start or end at a different address than a 64-bit value.