Add Swiss German language to l.d.o

It is possible that the localization server misses some features that are useful to the language you are referring to; basing on that, it could be that adding such language to l.d.o should be postponed.

It is possible that the localization server misses some features that are useful to the language you are referring to

Please make more concrete comments. Vague stuff like this will only confuse people.

I am a bit wondering which two-letter code to use.

After some discussion with Miro in IRC, we've found that we probably should follow http://www.w3.org/International/questions/qa-choosing-language-tags

and

http://www.iana.org/assignments/language-subtag-registry

that is we'd start with de, attach gsw with a hyphen and then attach something for Berndüütsch, I've seen "bed" used at Wikipedia.

That way we would end up with "de-gsw-bed".

Just to complete the source of research we did:
http://www.w3.org/International/
For an example of an other region and wikipedia relying of parental gsw region code:
http://de.wikipedia.org/wiki/Solothurner_Dialekt

I would strongly recommend for the Drupal project to rely on the new standard recommendations by W3C and the refering IANA registry. If someone of you could check these documents in deep detail and confirm the correctness of our initial direction?

As of my understanding we might need to register the bernese dialect first in IANAs registry to be in perfect standard conformity. I'm pretty sure IANA would be open for any inputs to complete the list as we try to do it ourself too.

At least, everything starts where killes pointed to:
http://www.w3.org/International/questions/qa-choosing-language-tags

Good luck!

I apologize for my comment.

I was referring to #561662-5: Add German language to l.d.o where it is reported that:

The German translation team used such a server before, but unfortunately this lead to several problems. There are still a number of problems with the l10n module that need to be solved before moving to localize.drupal.org.

If the reported problems are specific for German language (and they have not been resolved), I would guess that the same problems would be valid for the Swiss German language.
As for the Italian language has been replied that it would be better to wait some feature will be added to the localization server (and Italian language uses more simple letters than German), and sburkard@gmail.com asked if it was possible to do what he was asking for in the localization server, I just pointed out what reported in two different (but they could be more) reports.

Again, I apologize for what I said; please forget I said anything about this topic.

The German and Italian teams hold back because of missing features which are *not* specific to their language at all. So that cannot be extrapolated to any other language.

However:

It would of course be the most easy way to translate based on the high german translation - is this possible on localization server?

If you mean "branching" that translation, this is not amongst the features supported currently, but was requested by others as well. No ETA on that though, since we have more important requests to handle for the foreseeable future.

What he could do is to import the de.po as suggestions. Not sure this would be a good workflow.

Maybe it would be easier to first batch-replace certain words and then import the modified de.po.

@sburkard: please let us know how you want to proceed.

@killes: if we assume no maintenance, then yes, otherwise, doing this periodically sounds possibly more pain then gain.

I don't think that he'll want to update from the standard German periodically, the spelling is too different to make this worthwhile.

Hello

A one-time-import of the current high-german translations would allow us to use high-german as the "source-language". This would make the translation quite easier, since the translators do not need to speak english (or at least not fluently).
If there is a very easy way to look up the current high-german translation of an english string, this would also be a way, but no as easy.

About the language code: "gsw-berne" seems to be correct to me.

In http://www.w3.org/International/questions/qa-choosing-language-tags it is recommended to "use a single language subtag, rather than the language+extlang pair" (see Decision 2). Since gsw itself is a tag, it doesn't need "de" (except there is a technical reason in Drupal for that).
The second part would be a variant-subtag (see Decision 5 in the same doc). Therefore it has to be (according to http://www.inter-locale.com/ID/rfc5646.html#variant) at least 5 characters long.

@KiamLaLuno: Swiss german uses the same letters as english, plus the three umlauts (ä,ö,ü) - that's all. I can't imagine this alphabet raises any problems.

@Gabor: A very nice feature for the future of l.d.org could be to define a hierarchy of two languages as preferred source-languages. If available, the server shows the string to translate in the preferred one. If not, it tries the second one. If this is also not available, it just shows the english original. This would make things much easier for languages derived from another one like swiss-german is from german. Additionally it would also allow people who are not speaking english to participate on the translation.

Cheers
Stefan

A very nice feature for the future of l.d.org could be to define a hierarchy of two languages as preferred source-languages. If available, the server shows the string to translate in the preferred one. If not, it tries the second one. If this is also not available, it just shows the english original.

The problem is that the Drupal translation system uses English as source-language. When a module calls t() it passes the English sentence (or word) as first argument; if the function doesn't find a sentence in the current enabled language that is associated with the English sentence, then it returns the English sentence.
This is related with the fact that, without any translations installed, Drupal uses English as default language.

@KiamLaLuno: that does not make localize.drupal.org powerless to do such a fallback, since it is not using the Drupal localization system (because it does not give us the data granularity we need to translate).

@sburkard@gmail.com: I think we agree such a fallback would be nice, but as said, we currently have other priorities.

What I meant is that the exported translations (the files with extension po) must have an English phrase associated with the language to translate in. If the source language is German, i.e., a call like t('Block description') will not find the translation for Block description, and return that phrase.

I didn't mean that the translation server is not powerful; I was just wondering about the purpose of the feature reported, when the translation files used by Drupal use English as source language. It is possible to use a different language as source language, but then the translation file must use English as source language (I guess that in the example, somebody would translate German into Swiss German dialect, and then translate one of the language in English).

@KiamLaLuno: just think a little bit ahead. That a UI presents translations of English strings to German as a starting point for a Swiss translation does not mean the output is not going to relate English strings to Swiss strings. Anyway, as said above, this is not in our current priorities.

@sburkard, @miro: support for branching translations is ongoing at #608488: Branching a translation. Given that support for that seems to be far off, would you like to start with a fresh empty database, import German translations yourself and deviate from there? Later maintenance for version updates or improved translations will not be easy on you, but that is the only way we can offer for now.

Hi Gabor

Yes, I would like to start off without waiting for the branching-feature.

If we import the german translations, we have the english original text as source language and the translation prefilled with the german text, right?

By the way, what do you think about the language code (see comment #3 vs. #10)?

Thanks
Stefan

Hi Gabor

I think I gave the needed info in my comment #16. Therefore I set the issue's state back to «active».

If you need more info don't hesitate to ask.

Cheers
Stefan

Ok, sounds good, will add the group as soon as I get around to this.