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.

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: Translation inheritance. 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.

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

Sorry for holding this for long in RTBC, but I've been busy with other stuff and just started to process this queue again. The language code we use should basically be the language code used by browsers to identify this language. I tried to look at references for Swiss German, and found Firefox and hunspell referencing it as "de-ch". Much like pt-br and pt-pt is for two variants of Portuguese. Our choice should be as close to the browser language negotiation settings as possible, since that is how Drupal identifies the language files and uses that language code. If browsers request Swiss German pages with "de-ch", then we need language files with that name, so we need a language group of that name.

So the point is that no other browser / http client software supports this language code anyway, so we can just pick one of our own? If browsers or other HTTP clients have a language code used for this language, the reason we'd go with that is exactly because Drupal language codes translate down towards as deep as HTTP language negotiation.

Sorry for the delay. Created team at http://localize.drupal.org/languages/gsw-berne and made sburkard@gmail.com the initial owner / admin.

Please expect that there might be bumps in the service. You are among the beta-tester of this live instance. Thanks for helping out and please report issues as you find them! Your team members can now join and help import existing translations and work on more translations.

Anybody can sign up for being a member of the team and they will be able to submit suggestions right away. The initial admin can change permissions of people signing up, widening their capabilities. See http://localize.drupal.org/node/616 for explanation on how.

Welcome on board!

Not sure what happened, but now fixed. Do not revoke the translation community manager role from yourself anytime (this might or might not have happened in this case), or I need to grant it again :)