2015-02-26 22:27 GMT+09:00 Tom Fifield <t...@openstack.org>: > On 26/02/15 21:18, Sean Dague wrote: >> This morning in the nova channel we were trying to get to the bottom of >> the unit tests failing lxsi and gillard in en_GB on some string >> comparisons. Something is breaking down in our i18n null fixture for the >> tests. >> >> However, in trying to track down the route of their messages I ran into >> things like this: >> >> https://github.com/openstack/nova/blob/master/nova/locale/en_US/LC_MESSAGES/nova.po#L1410-L1411 >> >> >> https://github.com/openstack/nova/blob/master/nova/locale/en_US/LC_MESSAGES/nova.po#L3481-L3485 >> >> https://github.com/openstack/nova/blob/master/nova/locale/en_US/LC_MESSAGES/nova.po#L5790-L5793 >> >> >> https://github.com/openstack/nova/blob/master/nova/locale/en_US/LC_MESSAGES/nova.po#L3278-L3282 >> >> >> >> So, correct me if I'm wrong, but I think that means that when running in >> en_US those log messages are going to get overridden. And in many of >> these cases they are getting overridden to completely unrelated messages. >> >> That seems quite dangerous. Is there a reason that en_US locale tree >> exists at all (given that we've treated it as base locale historically). >> It seems like it's existence can only cause issues. >> >> What's the right way to test / checkpoint on this on a regular basis? >> >> -Sean > > > en_US does not exist on transifex. It existed once by mistake, but was > later removed. This is probably why it's in a weird state. I think that > file should be deleted.
"en" (or "en_US") language is a source language for all translations, so it should not be imported into our git repositories. It is the source languages, but if translations exist for these language gettext use it. The thing in nova previously occurred in Horizon one or two years ago. It was due to our misconfiguraitons in Transifex and after that en and en_US in Transifex were removed. If en and en_US locales exist in our git repositories, we can safely delete them and the infra translation script can ignore them. Thanks, Akihiro > > > Regards, > > > Tom > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev