13đź‘Ť
âś…
While you could do this fairly simply, I would question why.
As is:
- Django’s i18n is based around
gettext
, which has never given me any performance problems. - You don’t have to create the message file, Django will do it for you.
- The messages files Django creates can be sent as a text file to just about anyone for translation.
- I spent about 5 minutes explaining to someone how to use them, and a day later got back a fantastic translation of my entire site.
- Marking the strings in your code is very simple.
_("My String")
is normal for.py
files by usingfrom django.utils.translation import ugettext as _
.{% trans "My String" %}
in your templates. Again, quite simple.- Writing out
bundle.getString("My String")
seems like it would get old, quick.
- You can easily incorporate Django’s i18n into your JavaScript, if needed.
- There are web-based editors for the message files.
- You don’t have to define a string more than once, it conglomerates all instances into one token across your entire app.
- How many times do you have to define “Save” in your Java properties files?
- Still in a nice, version-tracking friendly, text file.
- If you hack together a
.properties
-like way to define your strings, you’d still want to compile them so that you don’t have to parse the text file at execution time.
Example of empty .po
file:
#: templates/inquiries/settings/new_field.html:12
#: templates/inquiries/settings/new_form.html:4
msgid "Save"
msgstr ""
Personally, I don’t see a reason to bother hacking together a replacement for a solution which already exists and works well.
👤Jack M.
Source:stackexchange.com