#30439: Translations issues on Django upgrade due to unexpected changes in 
plural
forms
--------------------------------------+------------------------------------
     Reporter:  Michal Čihař          |                    Owner:  Rodrigo
         Type:  Bug                   |                   Status:  assigned
    Component:  Internationalization  |                  Version:  2.2
     Severity:  Normal                |               Resolution:
     Keywords:                        |             Triage Stage:  Accepted
    Has patch:  0                     |      Needs documentation:  0
  Needs tests:  0                     |  Patch needs improvement:  0
Easy pickings:  0                     |                    UI/UX:  0
--------------------------------------+------------------------------------

Comment (by Rodrigo):

 Alright, it's going to take more time that I thought, here is my
 implementation plan:

 - Have 2 more options in compilemessages: --main-po and --initial

   --main-po is for addressing easily plural form changes in Django, you
 edit the plural form and then re-compile with it.

   --initial is for compiling all the pos distributed with Django.

 - Have a system check for i18n turned on and no mos available

 - Have a collectlocale command that does the same as collectstatic but for
 locale

 This is for addressing Claude's concern about repository size and not
 merging changes so often. There is no need - IMO - to keep under VC the mo
 files and distribute them when the can be easily generated by the user.
 There is duplication between the po and the mo, they have the same
 information but in different format.

 If mos are out of the repository, then Claude could merge easily any po
 changes and the distribution size will lower also. The only cost of this
 would be run "django-admin compilemessages --initial" on any new project
 that will include i18n. It could also be run automatically if the system
 check fails, I'm not sure where would this go.

 The need of a collectlocale command arises from the problem that any
 changes on the pos in the Django distribution will be overridden on
 upgrade. If you want to persist them across upgrades, you would need to
 take them the project directory. Then, if a settings.LOCALE_ROOT exists,
 use that as a starting point for the catalog merging. This would be the
 more complex to implement, and it would render the --main-po useless.

 I have already implemented the --main-po option and started with the
 collectlocale as a better option, has anyone have any thoughts on this?

 Here is the [https://github.com/math-a3k/django/commits/ngettext_fix
 branch] where I'll be working until the final PR is reached

-- 
Ticket URL: <https://code.djangoproject.com/ticket/30439#comment:18>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.9964a264adc3bdd83ece5163fad8d599%40djangoproject.com.

Reply via email to