django migration files with many languages

Using Django Mystery Errors
1

Does django makemigrations command work differently by language that the project uses?

I have two projects. One is upstream, and the other is origin. As you might expect, origin is forked version of upstream. Basically origin shares the codes with upstream, which means table schema is identical.

Here comes the problem. Upstream uses Korean.

LANGUAGE_CODE = "ko-kr"

Origin uses English.

LANGUAGE_CODE = "en-us"

Both have django.mo file respectively, in the right location accordingly (locale/ko/LC_MESSAGES/django.mo, locale/en/LC_MESSAGES/django.mo).

In upstream when I run makemigrations, no changed detected. In origin when I run the same command, a long list git changes occur. All of the changes are about verbose_name, choices label etc.

How do you make django recognise the right language when making migration files? Any thought?

This question is also asked in SO

2

Hey there!
I may be missing some details here, or you haven’t provided enough information about the issue.
But normally, the makemigrations is used to generate database migrations, and normally that’s nothing to do with internationalization. On normal scenarios if you need to generate the translation messages you would use the makemessages command passing the respective language to generate the .po files. Example for generating the messages on Brazilian Portuguese:

python manage.py makemessages -l pt_BR

Hope that helps, cheers.

3

Hi.

Suppose you have the following field

from django.utils.translation import gettext_lazy as _

class Model(models.Model):
    is_checked = models.BooleanField(verbose_name=_("확인여부"))

Here 확인여부 is written in Korean, and when you run make migrations, what migration file would you expect to have?

                    "is_checked",
                    models.BooleanField(
                        verbose_name="확인여부",
                    ),
                ),

Something right this I assume?

But the issue is, depending on language file in my theory verbose_name is printed differently in migration file.

python manage.py makemessages -l en

# msgid "확인여부"
# msgstr "Is it really checked?"

python manage.py compilemessages -l en

python manage.py makemigrations 

# migration file
                (
                    "is_checked",
                    models.BooleanField(verbose_name="Is it really checked?"),
                ),

This is where the problem comes. After I made mo file, verbose_name is differently wired.

4

Interesting, actually i mostly never change LANGUAGE_CODE in the middle of the project. So i don’t have an answer that may satisfact your criteria.
But one thing that you can do is to “trick” the migration system to NOT generate migrations that doesnt affect the database schema (verbose_name, help_text, and choices for example). For that you’re going to need to write a custom makemigrations command, or override the default one to not generate migrations from these changes. This SO post has a answer that may help on this.

Cheers.

1 Like
5

With that said, I just changed LANGUAGE_CODE in origin’s settings just in case. Guess what. No changes detected! Just as I wanted.

Of the trick, it’s not that I didn’t consider that. I actually have makemigrations command file, though I didn’t completely enforced it. The reason is because I’m not sure if that’s django way. One of django tickets is about that, and the seemingly maintainer wrote

I’d rather we included every single field - white/blacklisting fields is dangerous. What if a field subclass redefines help_text? What if it uses it to help populate ORM objects? I’d like to mark this WONTFIX.

Interestingly, the ticket also touches the issue of new migration files after changing locale (I haven’t studied the ticket thoroughly yet though).

For now I’ll see how I can leave the LANGUAGE_CODE as is and continue working on the project.

Thanks a lot. Cheers.