Add German informal to l.d.o

There's no active maintainer for this fork and it is very outdated. The development pattern we used can't be applied with l.d.o anymore. We used to tag the translations with #formal in the .po files which allowed us to create a file that just contained strings which used formal words which we then translated to informal. However, this might be a feature suggestion for the l10n_server.

Hm, I would love to get an informal version again (and would contribute also). I am in the process of doing my first translation and it honestly botheres me that I have to do a formal version which is not really suited for my own site.

Should this issue's status be changed to postponed until #608488: Translation inheritance is solved?

Maybe i am too naive, but i don't see technical showstoppers for this.
Given that we now have modules like Language Hierarchy, i can see it like:

* we add de-informal (or de-INFORMAL?) to l.d.o
* the good-willing will just use it, scratch their itches and sync back via Localization client
* (optionally we prepare a how-to page how to do all this)

... and hopefully this all will get some ball rolling (e.g. to port lang-hierarchy to D8, to improve l.d.o. workflow etc.

As board member of the german DA i'd take part in pushing this on Dec 1st 2016 Munich Camp.

Any thoughts, any objections to try this out and - as part of it - add de-informal to l.d.o?

Yes, that's what i think and want to push.
Relevant german strings can be clearly identified by grepping for "Sie".
Also i'd suggest using the l10n_client module to translate and upstream the translations.

BTW: cudos for l10n_client and language_fallback, i love it!

Hmm, to be honest i don't understand the question...

As i understand it, DE and DE-informal are totally unconnected languages to the client.
(The client does not know anything about the fallback...)

EDIT: ah you do NOT refer to the upstream-functionality, but the on-page-translation.
I just refer to the upstream functionality of the moldule, NOT the on-page-translation.
If the on-page-translation JS gets confused by the fallback is something we might test, but this would be no showstopper.
(I don't use it often anyway, as it seems to miss some on-page strings...)

see my edit above:

ah you do NOT refer to the upstream-functionality, but the on-page-translation.
I just refer to the upstream functionality of the moldule, NOT the on-page-translation.
If the on-page-translation JS gets confused by the fallback is something we might test, but this would be no showstopper.
(I don't use it often anyway, as it seems to miss some on-page strings...)

Even if we do not strictly need the l10n_client on-page-translation, i vgrepped it of interest. It should work, as strings are saved to the current global language.

function l10n_client_save_string() {
  global $user, $language;
...
        _locale_import_one_string_db($report, $language->language, $_POST['context'], $_POST['source'], $_POST['target'], $_POST['textgroup'], NULL, LOCALE_IMPORT_OVERWRITE);

But to clarify more: i'm refering to:
Localization client | Drupal.org

At the same time, if configured properly, the module also submits your translations back to the community, to localize.drupal.org or any other localization server.

Hmm, so the worry is this:
* translator uses DE-informal and translates "Sie Dödel" (You moron) with "Du Dödel" - OK correct.
* translator uses DE-informal and translates an untranslated "Hello user" with "Hallo Benutzer" - NOT correct as it should go to DE language.

I can think we can handle this with a good handbook page, and trust translators to make good karma and not unnecessary work.

If people use the general translation page, they will conciously choose DE / DE-informal so no problem.
If people choose on-page translation, they should have read that handbook page...

Hmm i think we bikeshedded this a bit. I can't foresee the future what people will do, but i think it is time to try and put energy into this.

So you think i can read your mind...?
Ironic nagging aside, thanks for sharing that concern. So l.d.o has no VBO for bulk moderation. So i hope too this will not make it to our urgent wishlist too early. Does l.d.o. provide REST for moderation? Invalid items ar regex'able so easily...

Just to note: the above problem is the same as swiss german has. In that case, the main problem is lack of contribution.

In any case: Having a solid language variant workflow is imho strongly needed.

Concering language code: Swiss uses gsw-berne which looks quite arbitrary to me. This SO post and that gettext doc suggest de@informal (which also would tell modules about the language hierarchy).

So i'd suggest
* de@informal IF our toolchain can handle the @-sign
* de-x-informal otherwise

OK thanks for answering my "bytheway" comment on swiss. Interesting.

What do you think about the suggestion? If you like choose different, you seem to know better anyway.