#9888 NORM 10.1.2: measure activity doesn't work with en_SZ.UTF-8 locale

[Zarro Boogs per Child]

#9888: measure activity doesn't work with en_SZ.UTF-8 locale
-------------------------------------------------+--------------------------
           Reporter:  wad                        |       Owner:  cjb                   
               Type:  defect                     |      Status:  closed                
           Priority:  normal                     |   Milestone:  10.1.2                
          Component:  acoustic-measure-activity  |     Version:  1.0 Software Build 802
         Resolution:  fixed                      |    Keywords:  XO-1 measure          
        Next_action:  no action                  |    Verified:  0                     
Deployment_affected:                             |   Blockedby:                        
           Blocking:                             |  
-------------------------------------------------+--------------------------

Comment(by edmcnierney):

 Quanta isn't misunderstanding anything, nor is Quanta deciding what LO tag
 values to assign.  They are (correctly) reporting a problem that occurs
 when the LO tag specifies a locale that isn't supported in our build.

 Using "locale -a" will correctly report the locales we have chosen to
 include in a given build, but that's a bit of a circular argument.  In
 this case (and in similar, as sayamindu noted 10 months ago) we should be
 implementing the required locale support and including it.

 The parallel with an Italian speaker in China isn't appropriate, as
 Italian is not one of the official languages of China.  English is an
 official language of Swaziland, and it is perfectly reasonable for the
 Swazis to want an en_SZ locale defined.

 Quanta only uses LO tag values specified by OLPC when an SKU is created;
 they don't invent them.  In this case I think there are the following
 problems, common to all such new locales:

 1. OLPC allowed an LO tag to be specified without including glibc support
 for it.
 2. No one created an en_SZ locale to fix the problem.
 3. setlocale() doesn't degrade gracefully

 If we are ever to support this SKU, we need to create the en_SZ locale and
 include it in our glibc build.  I think that's what dsd said 3 months ago.

-- 
Ticket URL: <http://dev.laptop.org/ticket/9888#comment:20>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system