Please add a filter for getting the language family from a given language code to the i18n tag library

[carsten.klein@…]

For my current project, I need an i18n filter that returns just the language family, or whatever it is called, from say 'en-us'. The family then would be 'en'. While I could add this as part of my project, I think that the feature would also be helpful to other users, hence my request.

A sample filter implementation would be:

@register.filter
def language_family(lang_code):
    return lang_code.split('-')[0]

Please note that although I am aware of your process, the above code snippet is so small, that I will not include a patch for the template tags library i18n.py here.

TIA!

[carsten.klein@…]

And while we are at it and because of that the small but faulty code might fail under certain conditions, make this:

@register.filter
def language_family(lang_code):
    return str(lang_code).split('-')[0]

:D

[Łukasz Rekucki]

I don't see an obvious use case for this filter and the description doesn't mentions a one. Not every one-liner needs to be in the core. And those that do, usually have documentation and tests that show that they do not "fail under certain conditions".

[carsten.klein@…]

Well, ok. The use case is that I want to include the language 'family' in the path of the URI lest the 'dialect' part of it. Say, if you have the English language 'en', then you also have multiple different 'dialects', for example 'au' or 'us' or 'en' :D.

Likewise for German, where you have de-DE or de-AT or similar such 'dialects'.

Of course, I could always also provide such a filter with every project of mine requiring to provide language specific URI paths. But since it is a no brainer, I thought it would be most fitting for django to incorporate such a small feat at nearly no cost nor side-effect, whatsoever.

[Luke Plant]

Incorporating anything in Django is never 'nearly no cost'. It has to be documented, tested and maintained for ever. Every piece of documentation also adds weight, making it harder for people to find the things they need, so it costs every person who uses the docs.

You also still haven't given an example of how you would use this to construct URI paths, so it's hard to tell if it's a good solution to a common problem.

[Aymeric Augustin]

For each supported language, django.conf.locale.LANG_INFO provides bidi, code, name and name_local.

Django provides template filters to obtain bidi, name and name_local for a given code.

code is redundant because it's always equal to the key in LANG_INFO:

>>> from django.conf.locale import LANG_INFO
>>> [code for code, info in LANG_INFO.iteritems() if code != info['code']]
[]

This is consistent.

---

Introducing a new filter returning the 2-letter language code would create some confusion — "what's the code? de-at, de_AT, or de? why does LANGUAGE_CODE|code != LANGUAGE_CODE? Like you said there isn't a well known vocabulary to distinguish these various codes.

---

The use case you mentioned is reversing URLs in templates.

Django 1.4 adds support for including the langage in the URLs with the ​i18n_patterns feature. If you're rolling your own version of this (maybe because Django's implementation doesn't fit your requirements), having to implement a 3-line template filter to inject the 2-letter language code in your {% url ... %} tags sounds fair.

You can also write language|slice:":2"— it's less "semantic" but probably just as clear.

---

So, thanks for the suggestion, but at this point in the discussion, this doesn't cross my threshold of "sufficiently generic and useful to be implemented, tested and documented in Django".