getnikola/nikola — pull request #818 by ccanepa (2013-10-11 15:16:04+00:00)
Title: simplify locales

This change revamps the locale handling in Nikola.

**The goals**
* compatibility with windows
* consolidate some disperse and partially duplicated code
* give the user the option about which exact locale use with each language

**The change in a nutshell**
* Sanitized locales are calculated when conf.py is first loaded; after that the code deals only with sanitized locales.
* Sanitized locales and services related to locales live in nikola.utils.LocaleBorg
* LocaleBorg is also the authority for .current_lang
* Other pieces of code that were variants of 'current_lang ?' eliminated or defer to LocaleBorg().current_lang

**Backward compatibility**
* At the level of conf.py , full compatibility in installations where locale support was working
* At spec level: theres what I think a minor and reasonable restriction about what locales you can set: you can choose between the locales declared (explicitly or not) in conf.py

**api compatibility**
* deleted nikola.nikola.s_l (the templates get the functionality trough LocaleBorg.set_locale, transparently)
* deleted get_month_name (moved to LocaleBorg.get_month_name, uses in nikola code adjusted
* Post.current_lang deleted, uses replaced with direct invocations of LocaleBorg().current_lang

For strict compatibility I should have deprecated and retained those deleted, serving people who subclassed some parts of nikola.
I guessed there are no people using directly those functions but if desired, I can undelete those.

**new feature**
User can specify the exact locale to use with each language in conf.py
There are three new optional settings in conf.py related to locales

LOCALES: dict of lang: locale key-value pairs. His keys must be keys of TRANSLATIONS. Some or all keys can be omitted.

LOCALE_FALLBACK : locale to use when an explicit locale is invalid (if not set, two hardcoded locales are tried, "en" and "C", the later should be available in any host)

LOCALE_DEFAULT: guides the handling of implicit locales

An explicit locale for a language can be specified in LOCALE[language].
Explicit but invalid locales are replaced with the sanitized locale_fallback
Languages with no explicit locale are set to
the sanitized locale_default if it was explicitly set
sanitized guesses compatible with v 6.0.4 if locale_default was None (or not present in conf.py)

**Things not done**
We may want to complete one or more of these before merging

* Update the conf.py template to show the new locale settings, commented out for compatibility
* If one of LOCALES[lang] changes, then all posts related to that lang should rebuild. We need to inform doit about this. ATM I have no clue about what and where, any help would be appreciated
* probably some spelling is bad
* Adjust testing.
* The current test suite don't cares for the state leaked between tests by LocaleBorg. As test begin to probe multilingual sites, this can be a problem.
* If we reset LocaleBorg in tearDown, two existing tests in test_rss_feeds.py fails because they not have a proper LocaleBorg state. In general, test that not instantiate a Nikola class (when conf.py is loaded) and need to use locale services or query the current_lang, will need to set an acceptable LocaleBorg state
* Currently for multilingual tests two hardcoded langs are chosen ("en", "es") so that we can instruct Travis to load the appropriate locale support; for devs convenience it would be a nice touch to allow to specify any two langs / locales to use in multilingual tests

**Misc**
* all tests (except doctests) green in windows
* locale sanitization tested in Travis as a separate subsystem, green
* I expect tests green on Travis, except for typos and other trivial glitches, and maybe except for side effects of LocaleBorg carring state between tests
* If you reached this point, have a nice beverage :-)