-
Yes, I had considered creating a module and had read the documentation, but honestly, it seemed like it would take more time and perhaps more of my own knowledge and involvement.
Therefore, I decided to create a second language, clone the English one, and then translate it.
In the end, I translated everything—all 8151 records—since it's very difficult to filter out those that correspond only to the frontend. I did it following the steps indicated by chatgpt: creating a new language in sys_localization_languages, cloning the English language in sys_localization_strings, generating a CSV file, translating, importing to a temporary table, checking, and finally updating the sys_localization_strings table for new language and clearing the cache.
It's working well, so far.
However, @PavelS 's comment has worried me, and I'd like to know what kind of problems I might encounter.
Thank you both very much.
-
Hello @Claudio Acosta Creating a language module isn't hard at all—I have 13 of them. I also struggled with how to handle it as quickly as possible, etc., and believe me, editing a language module is much faster, more organized, and you can be sure your translations will always stay in place, whereas if your database crashes, you'll lose everything. When you uninstall the module, the database gets cleaned up and no unwanted clutter remains; if you do it manually, you have to do everything manually again.
As for scaring you, I didn’t mean to, but I’ve had it happen where a mistake I made while manually entering keys threw my entire website off.
Which path you choose is, of course, up to you, and if this works for you, there’s no problem with it as long as you’re careful and make regular backups.
As for the frontend-backend language separation, you can handle it the way I have it shown in the screenshot.
-
Comment 'Hi @LeonidS @Pave...' to 'Frontend Key Groups'
Comment to Frontend Key Groups