Voting starts in March for the Drupal Association Board election.
This issue is created in the hopes of opening up discussion on the implementation of a locale [regional] formats framework that could be used to collect and automatically format/convert non textual data such as measurements, dates, telephone numbers, etc. There are a number of modules that extend Drupal's multilingual capabilities but they function independently and often have limited implementation. Some of the standard formats that could be provided include (2 samples provided for brevity, there could be many):
- Number formats: 1,000,000.00 vs. 1000000,00
- Date Formats: MM/DD/YYYY vs. DD/MM/YYYY
- Calender systems
- First day of week (Monday, Saturday or Sunday)
- Units of measure:
- Length: cm vs. inches
- Dry mass: kilograms vs. pounds
- Liquid volume: litres vs pints
- many other units
- Currencies: UK Pound vs. US Dollar
- Telephone formats: (999) 999-9999
- Dialing country codes: +011 44 for England
- Postal codes: 99999-9999
I see this as a basic framework provided by core that can be extended by contrib modules. Core could be responsible for detecting and providing the end users locale in the form of a country code. This could be obtained from browser info, stored user profile preferences, and site defaults, maybe IP detection etc. Contrib modules could extend the locale info by providing formats for specific data stored in fields. e.g. A locale_date module would provide date formats used around the world keyed by country code. It would also provide a date field that uses the site default date format or user selectable date format for collecting the data and storing it. Finally the module would provide formatters that would detect end user country code and format the date appropriately.
Existing modules of interest
- Format Number API provides a method to configure number formats (site default and user defined) with configurable decimal point and thousand separators. Currently only 6.x. Could be used to convert stored decimal/float values into locale based formatted numbers.
- Formatted Number CCK provides cck input of numeric types where thousands separator and decimal point are inherited from the Format Number API module. Could be used to collect locale based formatted numbers and store them as standard decimal/float values
- Measured Value Field provides CCK input of decimal/float values together with a unit of measure such as length -> cm. It also provides formatters that can convert the value to another unit and display it with the unit symbol or name.
- Calendar Systems provides support for different calendar systems like Iranian , Jalali , Hijir , Hebrew etc. This support is currently limited to display and data entry for date fields and the back-end date is always Gregorian (Timestamp). 6.x & 7.x!
- Country code Provide location-appropriate path and content handling based on user's country. 6.x - project halted due to core limitations?
- Units API Converts between various weights and measurements using the International System of Units (SI).
- how do i translate the numbers?
- how do i translate the numbers?
- how to translate numerical values for locale
- bengali numerical system
- Change default English numbers to Arabic numbers
- Translating orderdered list numbers
Here's a sample of some of the data for en_US:
<ldml> <identity> <language type="es"/> <territory type="US"/> </identity> <dates> <calendars> <calendar type="gregorian"> <dateFormats> <dateFormatLength type="short"> <dateFormat> <pattern>M/d/yy</pattern> </dateFormat> </dateFormatLength> </dateFormats> <timeFormats> <timeFormatLength type="full"> <timeFormat> <pattern>h:mm:ss a zzzz</pattern> </timeFormat> </timeFormatLength> </timeFormats> </calendar> </calendars> </dates> <numbers> <currencies> <currency type="USD"> <symbol>$</symbol> </currency> </currencies> </numbers> </ldml>
PHP 5.3+ Internationalization Functions
Pretty much all of this is useful but here are some quick call outs to useful functions.
The floor is yours
What would you like to see in framework like this?
Have thoughts about how this should be implemented?
Any pitfalls to look out for?