Hi,
two questions about the German translation[s]:
I could post a patch for this if you think this makes sense.
I suggest that we either agree on a special set of differences (like this one, which is the only one I can think of) and otherwise "link" the Swiss translation to the German one - or we drop it.
Cheers, ~Mik
Swiss German is not actually a written language, German is always written as 'High German', even by the Swiss.
On 12/25/06, Michael Bueker m.bueker@berlin.de wrote:
Hi,
two questions about the German translation[s]:
- Should the Umlauts in the translation file not rather read ä
instead of ä, Ü instead of Ü and so on? As I understand it, those labels get displayed without further processing, so this way, we would steer clear of any encoding issues, at least for the German labels and messages. I could post a patch for this if you think this makes sense.
- Do we need a Swiss German translation? The only major significant
difference is that there's no ß in Swiss German, but rather ss is used. But I don't think this warrants a separate translation which often lags behind the other German one and contains inconsistencies. I suggest that we either agree on a special set of differences (like this one, which is the only one I can think of) and otherwise "link" the Swiss translation to the German one - or we drop it.
Cheers, ~Mik
2006/12/25, Michael Bueker m.bueker@berlin.de:
Hi,
two questions about the German translation[s]:
- Should the Umlauts in the translation file not rather read ä instead of ä, Ü instead of Ü and so on? As I understand it, those labels get displayed without further processing, so this way, we would steer clear of any encoding issues, at least for the German labels and messages.
I could post a patch for this if you think this makes sense.
If you look at other localization files, no non-ascii chars are HTML encoded. This is the target of using UTF-8 to keep all chars in their raw format. Why should we make an exception for German? And even though, there's no significant advantage of having umlauts HTML encoded. Since RoundCube also uses localized strings in Javascript alerts and plaintext output, HTML encoding would mess up these.
- Do we need a Swiss German translation? The only major significant difference is that there's no ß in Swiss German, but rather ss is used. But I don't think this warrants a separate translation which often lags behind the other German one and contains inconsistencies.
I suggest that we either agree on a special set of differences (like this one, which is the only one I can think of) and otherwise "link" the Swiss translation to the German one - or we drop it.
I'm Swiss and it's my personal wish to have a Swiss German translation. Don't worry, I'll maintain these files myself and nobody else will have any extra work with them. And what are the "inconsistencies" you're talking about?
~Thomas
If you look at other localization files, no non-ascii chars are HTML encoded. This is the target of using UTF-8 to keep all chars in their raw format. Why should we make an exception for German? And even though, there's no significant advantage of having umlauts HTML encoded. Since RoundCube also uses localized strings in Javascript alerts and plaintext output, HTML encoding would mess up these.
Okay then. I wasn't really thinking globally there, but if stuff is handled the UTF-8 way, then we'll hopefully be okay :)
I'm Swiss and it's my personal wish to have a Swiss German translation. Don't worry, I'll maintain these files myself and nobody else will have any extra work with them. And what are the "inconsistencies" you're talking about?
Roundcube is your baby, so do as you please here :) I was looking at both tranaltions in translator.roundcube.net and I saw that de_CH is missing 'deletemessagesconfirm' and that some translations are different although they don't really need be IMHO, like 'loading' is "Daten werden geladen..." in de_DE and "Lade..." in de_CH.
Which reminds me of another issue: Language hacks such as "Select message(s)" for both singular and plural forms don't work in most languages. I think having separate labels such as 'deletemessage' and 'deletemessages' is not an elegant solution, but maybe we could make the labels part of a two-element array, selecting element 1 for 1 item and element 2 for more than one item.
Cheers, ~Mik
Michael Bueker wrote:
I'm Swiss and it's my personal wish to have a Swiss German translation. Don't worry, I'll maintain these files myself and nobody else will have any extra work with them. And what are the "inconsistencies" you're talking about?
Roundcube is your baby, so do as you please here :) I was looking at both tranaltions in translator.roundcube.net and I saw that de_CH is missing 'deletemessagesconfirm' and that some translations are different although they don't really need be IMHO, like 'loading' is "Daten werden geladen..." in de_DE and "Lade..." in de_CH.
Well, I usually update the de_CH translation as I introduce new labels but I haven't checked it with the translator yet. I will complete it once a new release is near. Swiss people write in "high" German but this doesn't mean that Germans would write it the same or even understand what the Swiss want to say. There's a dictionary available translating Swiss-high-German to real German and vice versa. This means that there are some differences between those two translations.
Which reminds me of another issue: Language hacks such as "Select message(s)" for both singular and plural forms don't work in most languages. I think having separate labels such as 'deletemessage' and 'deletemessages' is not an elegant solution, but maybe we could make the labels part of a two-element array, selecting element 1 for 1 item and element 2 for more than one item.
You're absolutely right. I also had something with an indexed array in mind: 0 => "no items", 1 => "one item", 2 => "many items". Should not be too complicated to implement. The rcube_label() function takes an array as argument and here we could easily add a 'number' parameter.
Regards, Thomas