[Dev] Chandler Internationalization .6 Specification is ready for review

[Brian Kirsch]

Ok,
You got it.

Brian

I18n G.A.L. wrote:

>Please - big pet peeve of mine - I18nManager NOT
>I18NManager.  I18n is an abbreviation, not an acronym.
>
>Andrea (A4a)
>
>--- Brian Kirsch <bkirsch at osafoundation.org> wrote:
>
>  
>
>>Hi Grant thanks for the feedback. Please see
>>comments in line.
>>
>>Grant Baillie wrote:
>>
>>    
>>
>>>Hi, Brian
>>>
>>>I had a look at the 0.6 i18n spec: Overall, it's a
>>>      
>>>
>>very nice carving  
>>    
>>
>>>of a set of tasks out of a big chunky rock of a
>>>      
>>>
>>problem :). Comments  
>>    
>>
>>>are below; quotes are from the doc and the text in
>>>      
>>>
>>[] is an attempt  
>>    
>>
>>>to identify which part of the doc I'm talking
>>>      
>>>
>>about.
>>    
>>
>>>[Overview][Goals and Objectives]
>>>
>>>      
>>>
>>>>The goal of this development cycle is to move
>>>>        
>>>>
>>Chandler from the 8- 
>>    
>>
>>>>bit english only space to the world of
>>>>        
>>>>
>>internationalization and  
>>    
>>
>>>>unicode.
>>>>        
>>>>
>>>When you say "8-bit english", do you really mean
>>>      
>>>
>>"ascii" (a.k.a. "7- 
>>    
>>
>>>bit")?
>>>      
>>>
>>Yes and no. I am referring to the Python string type
>>which is 8-bit so 
>>saying ascii would technically not be correct. But
>>really yes I am 
>>talking about ASCII.
>>
>>    
>>
>>>Nit-picky naming question: Should it be
>>>      
>>>
>>i18nManager or I18Manager? I  
>>    
>>
>>>guess it's hard to distinguish "I" and "1" in
>>>      
>>>
>>sans-serif fonts.
>>    
>>
>>Ok sure I18NManager it is. Also FYI, the
>>ResourceLoader is being renamed 
>>the I18NLoader since it is going to be used going
>>forward for more than 
>>just loading of media resources.
>>
>>    
>>
>>>[0.6 Strategy]
>>>Should maybe have a section about making our wx
>>>      
>>>
>>dialogs localizable.  
>>    
>>
>>>Would this be done by having localizable .xrc
>>>      
>>>
>>files, and if so, are  
>>    
>>
>>>there ways of making sure UI elements don't get
>>>      
>>>
>>"lost in translation"?
>>    
>>
>>I think this is an important point but I an not sure
>>this needs to be 
>>addressed in .6. Off the top of my head I would
>>guess it is going 
>>require a custom .xrc file for each locale that
>>requires layout 
>>alterations. This is gonna be a major pain not to
>>mention the 
>>enforcement issues.
>>
>>
>>    
>>
>>>[The 0.6 Strategy][CPIA]:
>>>
>>>      
>>>
>>>>3. Ensure that WxWidgets correctly converts
>>>>        
>>>>
>>keyboard input commands  
>>    
>>
>>>>to displayable glyphs in the correct language and
>>>>        
>>>>
>>perform character  
>>    
>>
>>>>set conversion when incoming textual data is not
>>>>        
>>>>
>>unicode
>>    
>>
>>>>4. Ensure that all displayable blocks render
>>>>        
>>>>
>>multi-byte unicode  
>>    
>>
>>>>correctly.
>>>>        
>>>>
>>>It might be worth adding to 4: wxWidgets needs to
>>>      
>>>
>>be able to display  
>>    
>>
>>>general multi-byte unicode correctly (not just
>>>      
>>>
>>multibyte unicode  
>>    
>>
>>>entered via an input manager). It would be
>>>      
>>>
>>interesting to see how,  
>>    
>>
>>>say, email messages with mixed R2L and L2R text
>>>      
>>>
>>will display on all  
>>    
>>
>>>platforms.
>>>      
>>>
>>+1
>>R2L what is that? Ha hah
>>
>>My guess is Chandler would barf but R2L is not a
>>priority for 1.0 
>>anyways. Would be great to have though.
>>
>>    
>>
>>><<<On reading further, this seems to end up being
>>>      
>>>
>>one of John  
>>    
>>
>>>Anderson's tasks:
>>>
>>>      
>>>
>>>>wxWdigets that display text are wrapping native
>>>>        
>>>>
>>Operating System  
>>    
>>
>>>>widgets
>>>>        
>>>>
>>>Is this realistic? e.g. aren't our table & grid
>>>      
>>>
>>controls non-native  
>>    
>>
>>>(I'm no wx expert, so I could easily be off base
>>>      
>>>
>>here)?>>>
>>    
>>
>>Good point I will follow up with the CPIA team and
>>see what the best 
>>option is here.
>>
>>
>>
>>    
>>
>>>From [Tasks for Katie]:
>>>
>>>      
>>>
>>>>Target languages of review could include Chinese,
>>>>        
>>>>
>>German, and Hebrew.
>>    
>>
>>>Hebrew (or Arabic for that matter) is a good one,
>>>      
>>>
>>since it will  
>>    
>>
>>>unearth a large can o worms... Our UI layout is
>>>      
>>>
>>pretty much hard- 
>>    
>>
>>>coded to be L2R: (e.g. positioning of (sidebar,
>>>      
>>>
>>summary, detail)  
>>    
>>
>>>views, position of icons in sidebar, alignment of
>>>      
>>>
>>text in sidebar,  
>>    
>>
>>>position of labels in detail view, alignment of
>>>      
>>>
>>text in detail view).
>>    
>>
>>>It would be good to call out whether this kind of
>>>      
>>>
>>layout  
>>    
>>
>>>configurability is or is not
>>>      
>>>
>>>a goal for 0.6 (my guess is not).
>>>      
>>>
>>Complex layout is not a goal for .6 so I will make
>>it more clear in the 
>>spec.
>>
>>Hebrew is merely for the design team to review. The
>>point is to get 
>>people thinking about these larger issues now even
>>though they will not 
>>be tackled in the 1.0 timeframe. R2L also will not
>>be tackled but German 
>>or Chinese might.
>>
>>
>>
>>    
>>
>>>[General]
>>>
>>>Somewhere, we probably need to point out that
>>>      
>>>
>>there is a lot of QA  
>>    
>>
>>>work involved in verifying that Chandler works
>>>      
>>>
>>well with input  
>>    
>>
>>>managers for different languages (especially given
>>>      
>>>
>>that these vary by  
>>    
>>
>>>platform, too). Maybe this would be an area where
>>>      
>>>
>>outside volunteers  
>>    
>>
>>>could help out.
>>>
>>>      
>>>
>>Agreed. I was waiting for feedback on the i18n
>>proposal before pointing 
>>out specific QA tasks to make sure there were not
>>going to be any major 
>>proposal changes.
>>
>>QA will have a very important job in
>>Internationalization.  Both manual 
>>and automated tasks will need to be performed on
>>each target platform 
>>and for each target language. It is not a trivial
>>task by any means. 
>>Volunteers are certainly needed.
>>
>>
>>
>>
>>
>>    
>>
>>><<<I wrote this before seeing Andrea's page, which
>>>      
>>>
>>is a much more  
>>    
>>
>>>comprehensive outline of QA issues here>>>
>>>
>>>[Some questions about the bigger proposal doc]
>>>
>>>Are we going to output # c-format (or something
>>>      
>>>
>>similar) in .pot  
>>    
>>
>>>files? In projects I've worked on in the past,
>>>      
>>>
>>inconsistent  
>>    
>>
>>>translated format strings have caused a lot of
>>>      
>>>
>>grief (unexpected  
>>    
>>
>>>raises, or crashes in C), and it would be good to
>>>      
>>>
>>be 
>>    
>>
>=== message truncated ===
>
>
>
>		
>____________________________________________________
>Start your day with Yahoo! - make it your home page 
>http://www.yahoo.com/r/hs 
> 
>  
>


-- 
Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
(415) 946-3056
http://www.osafoundation.org