Changes between Initial Version and Version 1 of Ticket #35973
- Timestamp:
- Dec 4, 2024, 2:57:17 PM (5 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #35973 – Description
initial v1 1 The is_valid_locale function in the makemessages management command uses a regular expression that doesn't account for locales with numeric region codes, such as es_419. The current regex r"^[a-z]+_[A-Z].*$"only allows uppercase letters after the underscore. This excludes valid locale codes that use numbers in the region subtag.1 The **is_valid_locale** function in the **makemessages** management command uses a regular expression that doesn't account for locales with numeric region codes, such as ''es_419''. The current regex only allows uppercase letters after the underscore. This excludes valid locale codes that use numbers in the region subtag. 2 2 3 This can cause issues when trying to generate message files for these locales. For example, running makemessages with es_419will not generate the expected message files, potentially leading to missing translations.3 This can cause issues when trying to generate message files for these locales. For example, running makemessages with ''es_419'' will not generate the expected message files, potentially leading to missing translations. 4 4 5 5 Proposed Solution … … 7 7 Modify the regular expression in is_valid_locale to include numeric characters in the region subtag validation. The suggested change is: 8 8 9 From: r"^[a-z]+_[A-Z].*$" To: r"^[a-z]+_[A-Z0-9].*$"9 From: 10 10 11 This change would allow the validation of locales like es_419 while still maintaining the expected format for other locale codes. This simple modification would ensure broader compatibility and avoid unexpected behavior when working with valid locales containing numeric region codes. 11 {{{ 12 r"^[a-z]+_[A-Z].*$" 13 }}} 14 15 To: 16 17 {{{ 18 r"^[a-z]+_[A-Z0-9].*$" 19 }}} 20 21 This change would allow the validation of locales while still maintaining the expected format for other locale codes. This simple modification would ensure broader compatibility and avoid unexpected behavior when working with valid locales containing numeric region codes.