cs <-> sk fallback / fallback list

[dittaeva]

I just talked to a native Slovak speaker who confirmed my impression from previous conversations with Slovaks and from the Wikipedia article on Slovak language, that written Czech and Slovak are about as similar and mutually intelligible as nn and nb. Thus cs and sk should fall back on each other as nn and nb do (only without the interference of macrolanguage 'no').

From my understanding of the code, that should be as easy as adding the appropriate lines for cs and sk under line 104 in the common routemap settings, right?

@siebrand do you know of any list of such similar and mutually intelligible languages as cs <-> sk and nb <-> nn? Also what would be the best route for the interface translation to sk, copy identical strings from cs, or just those that differ and make an exception in the percent complete requirement?

[siebrand]

On Sun, May 13, 2012 22:47, Guttorm Flatabø wrote:

@siebrand do you know of any list of such similar and mutually intelligible languages as cs <-> sk and nb <-> nn?

I am not aware of any fallbacks between cs and sk. As they don't exist in MediaWiki, I wouldn't implement them in WMT if I were you.

Also what would be the best route for the interface translation to sk, copy identical strings from cs, or just those that differ and make an exception in the percent complete requirement?

That would be polluting the localisations. I'd veto that practice to be applied to a product supported in translatewiki.net -- as far as I'm concerned is about as evil as adding machine translation for UI. If implemented, it should be dynamically in the software, or through a caching layer, that inserts fallbacks available in the chain. Most softwares usually only have one fallback language, though (English).

Please find the list of fallbacks from MediaWiki below this message ("language": "fallsbackto").

Siebrand

ab: ru ace: id aln: sq als: sq an: es anp: hi arn: es arz: ar av: ru ay: es ba: ru bar: de bcc: fa bh: bho bjn: id bm: fr bpy: bn bqi: fa bug: id cbk_zam: es ce: ru crh_cyrl: ru csb: pl cv: ru de_at: de de_ch: de de_formal: de dsb: de dtp: ms eml: it ff: fr frc: fr frp: fr frr: de fur: it gag: tr gan_hans: zh-hans gan_hant: zh-hant, zh-hans glk: fa gl: pt gn: es gsw: de hsb: de ht: fr inh: ru jut: da jv: id kbd_cyrl: ru khw: ur kiu: tr kl: da koi: ru krc: ru ksh: de kv: ru lad: es lbe: ru lb: de lez: ru lij: it li: nl liv: et lmo: it ln: fr ltg: lv lzz: tr mai: hi map_bms: jv, id mg: fr mhr: ru min: id mo: ro mrj: ru mwl: pt myv: ru mzn: fa nah: es nap: it nds_nl: nl nds: de nl_informal: nl no: nb os: ru pcd: fr pdc: de pdt: de pfl: de pms: it pt_br: pt pt: pt-br qug: qu, es qu: es rgn: it rmy: ro rue: uk, ru ruq_cyrl: mk ruq_latn: ro ruq: ruq-latn, ro sah: ru sa: hi scn: it sg: fr sgs: lt sli: de srn: nl stq: de su: id szl: pl tcy: kn tt_cyrl: ru ty: fr udm: ru uk: ru vec: it vep: et vls: nl vmf: de vot: fi vro: et wa: fr wo: fr wuu: zh-hans xal: ru xmf: ka yi: he za: zh-hans zea: nl

[dittaeva]

Also what would be the best route for the interface translation to sk, copy identical strings from cs, or just those that differ and make an exception in the percent complete requirement?

That would be polluting the localisations. I'd veto that practice to be applied to a product supported in translatewiki.net -- as far as I'm concerned is about as evil as adding machine translation for UI. If implemented, it should be dynamically in the software, or through a caching layer, that inserts fallbacks available in the chain. Most softwares usually only have one fallback language, though (English).

I'm assuming you think copying identical strings is what is evil?

Please find the list of fallbacks from MediaWiki below this message ("language": "fallsbackto").

Thanks, where's the list from?

[siebrand]

Op 14 mei 2012 om 05:49 heeft Guttorm Flatabø reply@reply.github.com het volgende geschreven:

I'm assuming you think copying identical strings is what is evil?

The assumption they are identical in different languages is evil.

Thanks, where's the list from?

"grep \$fallback" on language/messages/Messages. of MediaWiki core and cleanup of the result.

[dittaeva]

What say you @lonvia? should we implement any/all of these? I don't think there's much of a point to touch the non-standard codes for the time being, and country specific codes (such as 'de_at') should already fall back. The rest are mostly falling back to languages we have and could thus be useful.

[lonvia]

I suspect that the Accept-Languages header does a much better job selecting a fallback language then we could do. (Not to mention that automatic language fallbacks can become a political issue.)

As the comment in settings.py says: that config option is not really meant as a fallback mechanism but should only be used where a language code exists that will not have its own translation (or denotes a language group like no). In addition, you should be aware that this configuration is only used for finding localized tags. It has nothing to do with the user interface language. You'd have to check in django-localeurl how fallbacks can be defined for that.

[dittaeva]

Ok, I see, I haven't been understanding it correctly then, but I doubt that the Accept-Language header will do a better job than a fallback list could do, although I do not know how russian language browsers are set up. Firefox is f.ex. trying to do some magic with no/nb/nn.