Change Details

We implement commafy, digit transformation based on current language, and decimal separator changes in Language.php. The commafy is now based on the CLDR Unicode TR 35 based digit grouping patterns. But the commafy implementation does not conform completely to TR35 spec. For example, the Language.php commafy method cannot parse a valid pattern like `#,##0.###` I propose to replace the number formatting implementation to use PHPs' [[ http://php.net/manual/en/class.numberformatter.php | NumberFormatter class ]] which is more advanced and standard compliant number formatter. **Fallback**: If NumberFormatter is not available, fallback to simple digit grouping of `#, ##0.###` format(English) and avoid our own implementation. Use digit transformation and seperator table transformation. **Known Issue** Arq - Algerian Spoken Arabic - has different number grouping seperator and decimal seperator than what is present in CLDR. **Can we remove the $digitTransformTable setting?**: Not yet since the frontend uses this for client side number formatting. Also separatorTransformTable is required for commafy $digitGroupingPattern is required for commafy. But the values of all these variables can come from NumberFormatter since it allows querying for pattern for a locale/language so that the frontend and backend implementation are not working on different data.

We implement commafy, digit transformation based on current language, and decimal separator changes in Language.php. The commafy is now based on the CLDR Unicode TR 35 based digit grouping patterns. But the commafy implementation does not conform completely to TR35 spec. For example, the Language.php commafy method cannot parse a valid pattern like `#,##0.###` I propose to replace the number formatting implementation to use PHPs' [[ http://php.net/manual/en/class.numberformatter.php | NumberFormatter class ]] which is more advanced and standard compliant number formatter. **Fallback**: If NumberFormatter is not available, fallback to simple digit grouping of `#, ##0.###` format(English) and avoid our own implementation. Use digit transformation and separator table transformation. **Known Issue** Arq - Algerian Spoken Arabic - has different number grouping separator and decimal separator than what is present in CLDR. **Can we remove the $digitTransformTable setting?**: Not yet since the frontend uses this for client side number formatting. Also separatorTransformTable is required for commafy $digitGroupingPattern is required for commafy. But the values of all these variables can come from NumberFormatter since it allows querying for pattern for a locale/language so that the frontend and backend implementation are not working on different data.

We implement commafy, digit transformation based on current language, and decimal separator changes in Language.php. The commafy is now based on the CLDR Unicode TR 35 based digit grouping patterns. But the commafy implementation does not conform completely to TR35 spec. For example, the Language.php commafy method cannot parse a valid pattern like `#,##0.###` I propose to replace the number formatting implementation to use PHPs' [[ http://php.net/manual/en/class.numberformatter.php | NumberFormatter class ]] which is more advanced and standard compliant number formatter. **Fallback**: If NumberFormatter is not available, fallback to simple digit grouping of `#, ##0.###` format(English) and avoid our own implementation. Use digit transformation and sepeseparator table transformation. **Known Issue** Arq - Algerian Spoken Arabic - has different number grouping sepeseparator and decimal sepearator than what is present in CLDR. **Can we remove the $digitTransformTable setting?**: Not yet since the frontend uses this for client side number formatting. Also separatorTransformTable is required for commafy $digitGroupingPattern is required for commafy. But the values of all these variables can come from NumberFormatter since it allows querying for pattern for a locale/language so that the frontend and backend implementation are not working on different data.