From: Brian M. <br...@gr...> - 2012-11-27 02:57:44
|
John, >> If we give the user the ability to change the locale/language in the > settings, then it isn't really a "const" anymore. The entire > application would have to be accustomed to checking the locale settings before > doing anything. This is probably a good thing. > > Ooh, that would be a PITA. What's more, I don't think that it would > work because the Gtk stock stuff gets its language loaded during gtk_init and > AFAICT doesn't provide for changing it. That's probably also true of > everything in Gramps's UI that isn't dynamic (like the "Go" > menu). That pretty much means that changing the primary language list will > require restarting Gramps. ISTM that's "const" for all practical > purposes. That makes sense. I just tried it in LibreOffice, and it requires a restart of the application for the settings to take effect. > Other localization facets like collation and date format can be handled, but at > the cost of a signal handler on everything that uses a localization facet to > regenerate with the new settings. Do we really want to go there? > >> >> I could imagine an entire module of useful functions: >> get_preferred_locale() - reflects current settings >> set_preferred_locale() - configured by user in the UI >> get_app_locale() - returns the locale that is actually used (may not > match "preferred" if it is not available) >> get_locale_list() - returns all locale names available for use >> get_locale( name ) - gets a specific locale by name (used by reports) > > > I don't understand the distinction between "app" and > "preferred" locale. If a locale isn't available, the user > shouldn't be able to set it from the UI. If the system changes and the > preference settings don't work, Gramps will have to fall back to the system > settings. Is that what you mean? Yeah. I had clicked around in LibreOffice (not sure if that is a good reference or not) and I was able to select from pretty much any locale you can imagine. I'm certain that I don't have all those locales installed on my system. So that was my reference. Maybe that is bad practice. Or maybe I didn't know what i was looking at. But my thought was that the list would have every locale on earth, and one special one called "default". In the case that the user selects a locale that isn't installed, the default would be used. If it is possible to query the locale system and find out what locales are available, then I propose we only provide the available locales in the list. I haven't investigated how to do that. It's complicated because the environment might have a locale installed, but gramps doesn't have a translation file (.po) that matches. Or, Gramps might have a translation file for a given language, but the system doesn't have a locale that matches it. I'm not sure how all that works. I'm glad you are here to figure it out :) > Thinking aloud a bit myself, I guess we need a Locale class. One instance will > be the app's, (appLocale) created at startup and existing for the duration > of the run. Others will be created per-report by copying appLocale, but the > report assistant will have a panel to modify it for that report (or for all > reports during that run of Gramps). That's exactly what I had in mind. ~BM |