getnikola/nikola — pull request #771 by ccanepa (2013-09-28 05:24:46+00:00)
Title: Simpler and more robust locale handling

Simpler and more robust locale handling

**don't merge, needs discussion and completion**

**Problems**

The current locale support does not work at all in windows.

Current locale code does implicit conversions between the nikola language selector ('en', 'de', 'ar',...) and the locale ('en_us', 'Spanish_Argentina', ...) which seems to be not working for some people even in linux.

The relevant code is somewhat dispersed, with a bit of duplication and sometimes unclear about if a symbol ('lang', 'locale',..) has semantics associated to 'selector of nikola translation' or locale. This mades more hard than necessary to fix or change the code.

**Proposed plan to fix that, from a high point of view**

1) Refactor the code in a way that
* preserves behavior in linux
* disambiguate symbols
* introduce explicit conversions
* moves into a single file the core functionality to see better this subsystem
* works in windows
* the goal is to clarify what data and functionality is involved, while keeping at very simple refactors. So no OOP or fanciness for the moment, this is a intermediate stage.

All of the above are done in the firsts three PR's commits, the logs tells in more detail the refactor intentions for each commit.

2) Decide on a Good Solution
I favor the 'be explicit solution':
* add a field in in each entry of config.py 's TRANSLATION so each translation tells which locale wants to use. This made all conversion decay to a lookup table.
* deprecate as earlier as possible the implicit style
* In the transition, we support the implicit style by building the lookup table using the functionality clarified in 1)

I'm open to other approach s.

3) Once decided which solution
* set the details seen by the user: which style of specifying locales, to exactly which revision we should be compatible, which diagnostics and warning,...
* implement keeping it simple

4) Tiding Up
* Some related methods were not clustered in stage 1, but are closely related (and partially duplicated). An opportunity to move those to the refactored subsystem
* Use OOP or something if appropriate
* move to the final location if utils.py is considered not proper

.