OpenSolaris

Locale Creator

The goal of this project is to enable a user to create and customize their own OpenSolaris locale without requiring a high level of technical knowledge. The output of localectr is an installable IPS package containing number of binaries and other supporting files with the locale data information. After the installation fully working locale is created on the OpenSolaris system.

Provide your recommendations/ideas at this blog. You can find usage demos (both command line and graphical) here as well.

 It has 2 interfaces:

• GUI – graphical user interface
• CLI – command line interface

A description of GUI user scenario:

1. Source of locale data:
   1. User has an opportunity to choose different locale data (CLDR) versions in "Choose version of locale data" combo box. Moreover it's possible to provide custom source of CLDR (by choosing "Download new locale data"). In this case it's needed to provide URL address with zip file which contains CLDR.
   2. User chooses source of data to load from the list of available locales. This list contains locale sources which are available in chosen CLDR. When a locale from the list is selected Locale Creator will automatically load and fill each field with default value. Once the locale has been loaded, its data may be customized if required.
   3. User has an opportunity to change default locale name (language plus region). For example he might want to create French-in-Russia-locale (fr_RU.UTF-8). The tag (optional) is appended to the name of the locale being created. Language and region names must not be blank. Language, region and tag names may contain only alphanumerical characters.
2. User modifies (creates) locale according to his/her needs, which includes:
   1. names of months and days, and their abbreviations
   2. short and full date and time format, date format, time format, 12-hour time format, “am” and “pm” symbols
   3. thousands and decimal separators, number grouping, characters for native numbers
   4. currency code and symbol, positive and negative signs, monetary decimal and thousands separator, monetary grouping, decimal places, positive and negative monetary formats
   5. “yes” and “no” values
3. After pressing “Build Package” command the application asks for further info:
   1. URL of IPS repository where we'd like to store the package.
   2. Location of cc compiler (needed in order to build locale data binaries). Not required if already in your $PATH.
4. With this information, the application will create the installable package and send it to the specified IPS repository. Once the package is created, it can be installed using the pkg(1M) utility. Finally, gdm login may not contain record of newly created locale. In this case you can add this record manually into /etc/X11/gdm/locale.alias file (with root permissions).

A description of CLI user scenario:

• this interface can only generate package for some locale with default locale data
• no locale tailoring is permitted
• is able to generate more packages for various locales within one command
• displays help, programme version
• it supports following parameters: |Option|Description

Some other issues

• Previews of the data settings are visible to the user in the GUI. For example, if a user customises the date format, it will show the effect of the change using today's date as an example.
• Generates UTF-8 locales only.
• GUI displays full description of the locale. Users can not be expected to know ISO language and teritory codes so the GUI will also display the description of the locale, for example: Afrikaans - South Africa for af_ZA
• Once the locale data is decided, it will be validated. Data validation is a locale independent data integrity check that the data provided falls in the expected ranges. For example, currency code must be 3 characters long and in the range A to Z.
• Generated locales can be cloned. Once the locale package has been generated, the same locale can be easily installed on multiple OpenSolaris machines by using pkg(1M).
• Locales previously installed can be uninstalled. By using pkg(1M) to remove the appropriate locale package.

Proposed enhancements/modifications

1. Possibility to generate also non-UTF locales
   1. actual version of the SW creates only UTF-8 locales
   2. let the user choose which encoding should his/her locale use
2. Support for modifying already installed locale without a need to create completely new locale
   1. nowadays after each modification LocaleCreator creates completely new locale. So that after a minor change there are 2 locales installed in the system (original and a new one)
   2. make opportunity to modify already installed locale without a need to create a new one
3. Enhance command line interface
   1. existing version supports CLI, however this interface cannot modify locale, only makes packages, what doesn't correspond with the aim of the programme
   2. improve CLI functionality (for example via parameters choosing URL with CLDR location, create dialogs which would modify locale data values, ...)
4. Users' feedback
   1* program would after successfull package creation optionally send LDML file (or any other information) to some firm's address
   1* program would contain some links on pages, where it's possible to fill survey about the application, notify which locales would user like to have in the system, or perhaps report any bug found in the software
5. Saving
   1* during locale modification it would be possible to save changes, what means saving XML (LDML) file, that'd be different from the original in our modifications.
   1* this LDML file would be possible to load repeatedly and continue its editing
   1* eventually users could distribute this file between each other, and without any more modifications they would just load it and create package with new locale
6. Various GUI improvements
   1* “undo” - changes being made would be possible to undo
   1* “about”- GUI would show application version plus some other features
   1* add some other locale data settings - analyze which POSIX locale data values are possible to use and those missing in the current version would be added
7. Logging
   1* optional part of the application
   1* logs would be saved in a default directory (probably in /var/log/)
   1* logs about which locale was created, by whom and when
   1* any error messages would be also saved to some default directory

Provide your recommendations/ideas at this blog. You can find usage demos (both command line and graphical) here as well.