Support for LANGUAGE_CODE in commands

[qcaron]

Do you plan to support LANGUAGE_CODE in manage.py commands? It would be nice to be able to add/update/delete for all of the project's locales.

[PLNech]

Hi @qcaron, thank you for this suggestion and sorry we took a long time to come back to you!

After reading the Management commands and locales section you linked to, I'm not sure to fully understand what you are asking for. Could you describe how you would interact with such a localised command to add/update/delete your project's records?

[PLNech]

Closing in absence of a reply, feel free to reopen the issue if you have something to add.

[qcaron]

Hi @PLNech

How funny it is to come back to this ticket 3 years after... I now have more clue about this!

Please have a look here. This is for Django 1.11 which is the version I currently use but from 1.7 up to 2.1: "By default, the BaseCommand.execute() method deactivates translations".

My use case
I have implemented a search index for a model that is used for multi-table inheritance. By doing this, I can search for pages, news items and event items for example (from Page, NewsItem and EventItem models). Like that, I use the same Algolia index. One search rules all models.

Those three models have a searchable_type field that is respectively equal to 'Page', 'News' and 'Event' when I run the algolia_reindex command. But the language of my site is Dutch and when I update a model instance through the admin, 'Page' is translated to 'Pagina'.

This impacts the search and particularly the searchable_type facet since the possible values are clearly displayed and there is now a dichotomy:

---

Based on the Multilingual Search documentation page, I come up with three options to address this issue.

Option 1
Add a use_settings_language flag to automatically use the settings language.

We can provide a given settings file to any manage.py command with the settings option. This could be quite painful for developers to maintain settings files for development, testing, staging and production environments though...

Option 2
Add a language-code option to specify which language code should be used.

Option 3
Add a one-index-per-language flag so all languages listed in the settings' LANGUAGES constant are used one by one.

Option 4
Add an attribute to the AlgoliaSearchIndex but this does not seem so clean to me.

Common work for all options

1. Compute the index name to create/clear/reindex. Indeed, if the index_name is initially equal to 'my_index', we would have 'my_index_nl' for Dutch.
2. Probably slightly update what commands display to provide information about the language(s) that were used

---

Please feel free to give your feedback and ideas!!

[qcaron]

@PLNech @clemfromspace
I cannot re-open this issue as stated here: https://stackoverflow.com/questions/21333654/how-to-re-open-an-issue-in-github (last bullet point of selected answer)

Could you do that for me? Thanks! 🙂

[PLNech]

Hi @qcaron, glad to see you again here after such a long time 🙂

Issue reopened, I'll let @clemfromspace and @julienbourdeau check it out as they are now leading the works in this integration :)

[tkrugg]

dup #252