1

In a big set of files I need to transcript non-ASCII letters (especially umlauts and es-zed) as something easy to type and also easy to read. This precludes the usage of something like ü or \"u for ü.

The easiest way is to use ae, ue etc. and ss for ß, however such a transformation is not invertible, as there are words like neue or Dauer where ue occurs. So I'm curious if the invertibility can be achieved via a list of exceptions.

Is there any German word where it's impossible to get the original back from such a transcription?

I noticed that there the occurrences of ue in a German word are usually preceded by a vowel. Is there a rule which would allow to minimize my list of exceptions?

maaartinus
  • 111
  • 3
  • 2
    You may get problems with names. Some names are written in different versions (The town Moers has no ö, but there is a name Mörs. Esslingen am Neckar changes its writting from Eßlingen, sometimes the old writting is still used (e.g. in Eßlinger Zeitung) – knut Dec 02 '13 at 08:19
  • 1
    Wouldn't this be more fit at SO / Programmers?? – Vogel612 Dec 02 '13 at 14:50
  • @knut: OK, if all exception are like this, I don't have to worry (no Mörs there and no need to exactly reproduce the old writting). Thanks. – maaartinus Dec 03 '13 at 04:15
  • @Vogel612: I don't think so... the programming part is something I can surely handle myself (though "how to achieve maximum efficiency" would be a good question) and I was mainly interested in the language-specific part. – maaartinus Dec 03 '13 at 04:18
  • 1
    @maaartinus actually this isn't language-specific. it's more like: how can i encode a file with non-ascii signs to ascii and back, an get the same content again. this is not specific for german (even though you ask for german umlauts specifically). in French for example: \´^these can be put above everyaeiou` – Vogel612 Dec 03 '13 at 07:41
  • 8-bit extended ASCII is not an option? – Takkat Dec 03 '13 at 10:39
  • Note that Moers is the current spelling of that place. Also note that there are place names in which any heuristical restoring of umlauts will not only inevitably fail to restore the correct spelling, but will also produce a spelling that does not reflect the pronunciation, like Soest or Kevelaer, where the e does not indicate an umlaut, but length of the vowel. – Wrzlprmft Dec 03 '13 at 22:06
  • 1
    @Vogel612: I know that there are similar problems for other languages, but they're not the same. For example, there's no way to restore Czech diacritics without understanding the whole sentence (there are words different in diacritics only). And the second part of my question (ignored up to now) concerns German only (I guess I wan't very clear). – maaartinus Dec 03 '13 at 23:10

3 Answers3

2

As a programmer I can't help but state that first of all it's a matter of file encoding. Use the correct enconding and leave everything as it is.

Having said this: We've had that case many times and have encountered the following problems:

  1. You'll always find a special character that you also need to change. Proceed only if you're absolutely sure that German umlauts and ß are all you need (otherwise it will drive you nuts)
  2. While using ae, oe, ss, etc. may sound like a good idea, it is in most cases not, as there's no way of 100% reverting it to original state. For example: to decide whether the name Gasse needs to be reverted to Gaße you need to know whether the a is short or long. There are even cases, especially with names, where the name is pronounced Gasse, but written Gaße for historic reasons. Or take Goethe. It will always be spelled Goethe and not Göthe.
  3. Everything you do to "encode" umlauts and special characters makes the text less readable. You could do this to transfer data when you can only use ASCII and convert it back on the receiver side, but for making the text human readable this is mostly not feasible.

As a side node: Using any character to escape other characters makes it necessary to find some way to escape that character if you want it printed. For example, in your suggestion, the following would happen:

\:Überlingen would become \:\:Uberlingen.

What would your parser do with the first \:? And does it make the text more readable? Or even worse: How can you expect somebody to write like that?

Thorsten Dittmar
  • 15,912
  • 1
  • 25
  • 52
  • I fully agree that a proper file encoding would be the best thing, but unfortunately, it's not an option. Ad 1: There are some other offending characters, but there are very rare (and I have an ugly but working solution for them). Ad 2: I see there are words where there's an ambiguity (this was the first part of my question), but I also see that they're rare enough. I'm confused concerning using \" which I've never proposed. – maaartinus Dec 11 '13 at 07:09
  • I know you didn't propose the \:. But I'm sure you can come up with a sample where \" creates the same problem I described for \:. – Thorsten Dittmar Dec 11 '13 at 07:48
  • OK, I see... the \" comes from TeX and is real PITA to type. But obviously there are people doing this. Any such prefix can be handled easily, as an example see the handling of backslash in C (and many other languages). – maaartinus Dec 11 '13 at 09:39
1

My suggestion would be:

ä -> a:
ö -> o:
ü -> u:
Ä -> A:
Ö -> O:
Ü -> U:
ß -> Ss
: -> ::
Landei
  • 2,475
  • 16
  • 16
1

As a programmer I would suggest that the easiest way is to use something like \"u . There is no easy logic when the author used ue to express ü. Also mind that using ss for ß is wrong. It's also correct German to write ue instead of ü!

The suggestion from Landei may be ok. But think about "Hier ist mein Foto: [img file]" then you would change that to "Hier ist mein Fotö [img file]" which is wrong.

So use something you are absolutely sure won't exist in your data. \"u could exist but it wouldn't be correct German.

RegDwight
  • 2,335
  • 1
  • 21
  • 33
Londane
  • 463
  • 1
  • 3
  • 12
  • 1
    You did not read Landei's suggestion carefully enough. If the transcribed text was “Hier ist mein Foto:” then the original would indeed have been “Hier ist mein Fotö”. If the original would have been “Hier ist mein Foto:” then the transcription would have been “Hier ist mein Foto::”. – Carsten S Dec 02 '13 at 17:17
  • @CarstenSchultz thats true. But op want also wants to parse it! So if he first processes the sentence "... Foto:" he will make that to : "... Foto::". If he parses it he will see: "... Foto::" and will make that to "... Fotö:". Now you can argue that you also can add a lookahead to your logic which looks how much ':' are following. but this makes it more complicate and not as performat. – Londane Dec 02 '13 at 17:19
  • Looking for sequences of colons and and deciding if their lengths are odd or even does not seem that complicated to me. – Carsten S Dec 02 '13 at 20:25
  • @Londane: Good point, but the readability of something like Gr\"\ssenma\ssst\"abe is pretty close to zero (compare with Groessenmassstaebe). If there was a simple logic, I'd use it; without it I can use an exception table. – maaartinus Dec 03 '13 at 04:25
  • @maaartinus there is no easy logic and your exception table would be huge. Maybe a look at nächtlich-Weihnachtlich helps you. So it could be that someone has to change entries in this exception table if there are changes in the language. The last german language reform changed some ß to ss. – Londane Dec 03 '13 at 08:23