[Chandler-dev] [proposal] more directory renames/moves

Brian Kirsch bkirsch at osafoundation.org
Fri Apr 14 16:04:39 PDT 2006

Hello All,
The migration of dialogs from application/dialogs seems like a good time 
to address bug 3576:

Summary: Dialog code reorganization for localization and PyICU support
URL: https://bugzilla.osafoundation.org/show_bug.cgi?id=3576

Taken from bug 3576:
The reorganization of the dialog code is a high priority.

Our .7 goal of shipping Chandler with one or more localizations requires 
all the dialogs:

1. Are no longer hardcoded via a GUI tool such as wxDesigner.
2. Leverage wxWidgets .po translations for common components such as the 
3. Wrap non-wx localized text in _() and use the Chandler i18n translation
4. Are flexible enough in layout to support text length expansion on

FYI, I have not yet been able to figure out how to localize the 
wxWidgets layer in Chandler.

What we want is for wx dialogs to automatically translate themselves 
based on the current locale set
using the .po translation files that ship with the wx release.

So for example a button with the text "Yes" in the EN locale would be 
to "Oui" in the FR locale by wx.

I have tried a few different ways of initializing wx localization based 
on the docs on the web site but so
far no luck. Maybe David S. might have a suggestion.

Here is one of the things I tried:

   import wx, gettext
   mylocale = wx.Locale(wx.LANGUAGE_FRENCH)
   wxpath = os.sep.join([Globals.chandlerDirectory, 'release',  'share', 
   mytranslation = gettext.translation("wxstd", wxpath, ['fr'])

Anyway, we should have a quick chat on IRC and see how much of bug 3576 
we can tackle during
the dialog migration.


Brian Kirsch -  Cosmo Developer / Chandler Internationalization Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105

Alec Flett wrote:

> I'd like to suggest we get rid of all the specialized dialog boxes in 
> application/dialogs and move them to their respective places in the 
> application.
> I was going to suggest that some end up in osaf/framework/blocks but 
> then I figured people might object since they're not actually blocks. 
> I think that the fact that they are blocks are irrelevant and they 
> just belong in the appropriate application area.
> Obviously this is stuff that would happen in alpha3, but I figure we 
> can work out the plan now and I can try to execute on it when alpha3 
> arrives.
> So I'm proposing:
> 1) rename osaf/framework/blocks to osaf/ui, and make sure these are 
> just base block/widget classes
> 2) rename osaf/views/main to osaf/chandler/mainview
> 3) move osaf/framework/blocks/calendar into osaf/calendarui
> 4) move application/dialog/* into the right places:
>    - Account*, PublishCollection, RestoreShares, SubscribeCollection, 
> SyncProgress into osaf/sharing
>    - ImportExport into osaf/import
>    - RecurrenceDialog and TimeZoneList into osaf/calendarui
>    - move Util into osaf/ui
> I welcome modifications.. for instance:
> - I'm not sure about osaf/calendarui as a name, but I'd like to get 
> the CalendarCanvas stuff out of osaf/framework/blocks. Maybe 
> osaf/chandler/calendar instead?
> - I'm also not sure about osaf/chandler/mainview - seems awkward. I 
> considered just osaf/chandler but then thought maybe pje would want 
> 'osaf.chandler' to be the main app (what he intended for osaf.app) - 
> would it be ok to depend on osaf.chandler.mainview in that case? Maybe 
> nobody should need to depend on that at all?
> Thoughts?
> Alec
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev

More information about the chandler-dev mailing list