`zh_CN` for Simplified Chinese
Notice here that the region code should be in capital letters for the
`django.po` file in the directory to correctly work.
If we do `makemessages` as
`python manage.py makemessages -l zh_cn`
OR
`python manage.py makemessages -l zh-cn`
It wouldn't work and no error is produced even after running
compilemessages, which can leave people baffled for a while.
I would suggest adding a warning/error messages if the locale is used
incorrectly. That would certainly be a great help.
I can make a patch for this as well.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* owner: nobody => darvid7
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:1>
* stage: Unreviewed => Accepted
Comment:
We have to be careful in deciding what is a "good" and a "bad" code.
However I agree that we can avoid some mistakes, notably the confusion
between IETF language tags [1] and ISO/IEC 15897 (Posix) [2] codes
generally expected by Django.
[1] https://en.wikipedia.org/wiki/IETF_language_tag
[2] https://en.wikipedia.org/wiki/Locale_(computer_software)
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:2>
* owner: David => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:3>
Old description:
> The translations only work when the locale involving region code is
> generated as this:
>
> `zh_CN` for Simplified Chinese
>
> Notice here that the region code should be in capital letters for the
> `django.po` file in the directory to correctly work.
>
> If we do `makemessages` as
>
> `python manage.py makemessages -l zh_cn`
> OR
> `python manage.py makemessages -l zh-cn`
>
> It wouldn't work and no error is produced even after running
> compilemessages, which can leave people baffled for a while.
>
> I would suggest adding a warning/error messages if the locale is used
> incorrectly. That would certainly be a great help.
>
> I can make a patch for this as well.
New description:
Hey Calude,
What about normalizing the directory name to something that would just
work.
For example,
No matter, if the developer is doing all these:
`python manage.py makemessages -l zh_cn`
`python manage.py makemessages -l zh_CN`
`python manage.py makemessages -l ZH_CN`
`python manage.py makemessages -l ZH-CN`
etc.
we, just normalize the directory name to `zh_CN` and it would work.
I'm still about to read the code of `makemessages` command and probably if
there are any more checks than just this, then we'll have to figure out
another way all together.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:4>
* owner: (none) => MattSegal
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:5>
* has_patch: 0 => 1
* version: 2.1 => master
* type: Bug => Cleanup/optimization
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:6>
Comment (by Matt Segal):
PR Ready
[https://github.com/django/django/pull/10345]
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:7>
* cc: Vishvajit Pathak (added)
* owner: Matt Segal => Vishvajit Pathak
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:7>
Comment (by Vishvajit Pathak):
[https://github.com/django/django/pull/10365]
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:8>
* needs_tests: 1 => 0
Comment:
[https://github.com/django/django/pull/10365 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:9>
Comment (by Claude Paroz):
I think I would still output a warning when a language code is normalized,
just to inform the user that its input has been corrected.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:10>
Comment (by Vishvajit Pathak):
Warning added when a language code is normalized.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:11>
Comment (by Nick Pope):
Trying to coerce ''any'' input to something like a
[https://www.w3.org/International/articles/language-tags/ language tag]
only to hack it back to a
[https://www.gnu.org/software/libc/manual/html_node/Locale-Names.html
locale] using {{{to_locale()}}} feels like a kludge. It would be better to
improve documentation.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:12>
Comment (by Claude Paroz):
Improving documentation is welcome, but silently accepting a wrong
language code also look a bit suspicious. I think I would be happy with a
warning without coercing anything.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:13>
Comment (by Vishvajit Pathak):
We definitely need to improve the documentations. Coercing the language
code is something we have to take call on.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:14>
Comment (by Nick Pope):
Replying to [comment:13 Claude Paroz]:
> Improving documentation is welcome, but silently accepting a wrong
language code also look a bit suspicious. I think I would be happy with a
warning without coercing anything.
I agree. I think a warning would make sense, without coercion.
It is still possible to provide a locale to {{{makemessages}}} where there
are no actual message catalogs in any of the paths in
`settings.LOCALE_PATHS`.
We should probably scrap all the normalization stuff and just output a
warning message if a locale specified by the user is not in
{{{all_locales}}}.
At the moment we output a {{{"processing locale xx_XX"}}} message if
{{{verbosity > 0}}} which should be fixed to only happen for valid,
existing locales.
As an aside, this is checking {{{--locale}}} for {{{makemessages}}}, but
what about {{{compilemessages}}}? (And are their any others?)
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:15>
Comment (by Vishvajit Pathak):
Now I am thinking more to avoid the coercing and to put just a warning
message.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:16>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:17>
Comment (by Vishvajit Pathak):
Tim
Current implementation involved just adding the warning message. We are
not normalizing locale now.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:18>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:19>
Comment (by Vishvajit Pathak):
Tim,
I would like to understand better what needs to be done next ?
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:20>
* needs_better_patch: 0 => 1
Comment:
As commented on the pull request, you cannot use the `all_locales`
variable as a reference as it does not contain new (valid) language codes.
The modified test in your patch shows a `'Invalid locale en'` message
which is obviously wrong, isn't it?
You may try using the
`django.utils.translation.trans_real.language_code_re` to check the locale
code syntax.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:21>
Comment (by Sanyam Khurana):
Hi Vishvajit!
Are you still working on the bug? Do you need any help?
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:22>
Comment (by Vishvajit Pathak):
Hi Sanyam,
Yes, I am working on this ticket but your help would be very appreciated.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:23>
* status: assigned => new
* cc: Vishvajit Pathak (removed)
* owner: Vishvajit Pathak => (none)
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:24>
* owner: (none) => Abhith Krishna
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:25>
* owner: Abhith Krishna => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:26>
* owner: (none) => Mark Dawson
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:27>
* cc: Herbert Fortes (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:28>
Comment (by Herbert Fortes):
Hi,
Here my thoughts:
language_code_re gets 'pt_BR'. And it does not get 'ZH-CN'. I did this:
{{{ r'[a-z]{2}(_[A-Z]{2})?' }}}
It seems to work. But one test prints:
{{{
System check identified no issues (0 silenced).
Invalid locale d
Invalid locale e
.................................................
----------------------------------------------------------------------
Ran 49 tests in 1.425s
OK
}}}
I did a check and there is only one line - 740 - that's use
{{{locale=LOCALE}}}. All
others use {{{ locale=[LOCALE]}}}.
What do you think Mark?
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:29>
Comment (by Herbert Fortes):
I forgot to say that the regrex I sent fails to:
{{{
ja_JP_JP
no_NO_NY
th_TH_TH
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:30>
* owner: Mark Dawson => (none)
* status: assigned => new
Comment:
I'm going to de-assign this because there's been progress, so that someone
looking can pick it up.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:31>
* owner: (none) => mdsheerazaziz
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:32>
* status: new => assigned
* owner: (none) => Ashish Mohite
* status: assigned => new
* owner: Ashish Mohite => (none)
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:33>
* owner: (none) => dk
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:32>
* owner: (none) => Rohit Jha
* owner: (none) => Aniket118
Comment (by Manav Agarwal):
Can I claim this? I think I can move this forward
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:33>
Comment (by Carlton Gibson):
Hi Manav, please do, no need to ask (but can I advise that you take just
one at a time to begin :)
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:34>
Comment (by Claude Paroz):
The problem with using `LANG_INFO` is that you exclude some extra
languages added specifically for a project.
You can try to use `language_code_re`, but you'll have to take into
account the language code vs locale code difference.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:37>
Comment (by Manav Agarwal):
[https://github.com/django/django/pull/13615 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:38>
Comment (by Manav Agarwal):
If the patch in [https://github.com/django/django/pull/13615 PR] seems
fine then please update me so that I may start working on tests.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:40>
* needs_better_patch: 1 => 0
* needs_tests: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:41>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:42>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:43>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:44>
Comment (by Manav Agarwal):
As per the
[https://github.com/django/django/pull/13615#issuecomment-726174242
comment by felixxm] on [https://github.com/django/django/pull/13615 PR], I
have created a check for the valid locales to not have hyphens.
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:45>
* needs_better_patch: 1 => 0
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:46>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"f63f3cdf0969c23fd0c05de0f4a2a1df0cd5112e" f63f3cdf]:
{{{
#!CommitTicketReference repository=""
revision="f63f3cdf0969c23fd0c05de0f4a2a1df0cd5112e"
Fixed #29712 -- Made makemessages warn if locales have hyphens and skip
them.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29712#comment:47>