I have a question regarding Django i18n and the django.po file.
I am new to i18n so please excuse my noobness.
I am using the Google Tranlator Toolkit to upload a text
file of English words and phrases.
In this case I am converting to Korean.
Here is a sample of four words:
Gender
Date of Birth
Country
City / Town
Here is the output on-screen:
성별
생일
국가
도시
When I click save it saves to a text file.
My questions is is it OK to use the Korean symbols
direct into my django.po file?
Everything is working OK in my application so far.
Looking at the django/contrib/auth/local/ko/LC_MESSAGES/django.po
file I can see it's using a format like:
msgid "Password"
msgstr "비밀번호"
So far it seems to work OK saving the symbols I have
but I'm just wondering if this is the corect way to do this.
So far I'm intending to use google to translate my English
into various languages and then I'll save them each
to their respective django.po file.
Any tips or advise much appreciated.
Thanks!
Good question!
I'm doing the same for my translation into portuguese, but I'm also, not quite sure, if it's the best way to achieve this.
Be careful if you aren't doing the translation manually but using this command
django-admin.py makemessages -l de
every time you update the file, check if everything is correct, because it can do associations, for instance I've writen:
first template:
pt = 'maça e cenoura'
second template:
pt = 'maça e cereja'
doing the automatic translation, it will assume both are equal strings, which they aren't.
I'm not able to explain why, because I don't know why this happen.
A solution could be to use a string 'X' and translate to both languages the text.
msgid = 'X'
pt = 'maça e cenoura'
en = 'apple and carrot' #different files (just as example, I put them together)
But like I told you, I'm also just starting using this feature
python manage.py makemessages -l ko output django.po default is ansi format,
you must convert it to utf-8 to allow non-ansi chars in it.
Related
Problem
I translate my group names in my Django application with the default translation tools.
Since my group names are not hard-coded in my code, when I run makemessages, the lines corresponding to my group names are commented out.
Example
I have a group named management_product which is automatically created during migrations. I put these lines in django.po:
msgid "management_product"
msgstr "Gestion des produits"
But if I run django-admin makemessages -l fr, they are commented out:
#~ msgid "management_product"
#~ msgstr "Gestion des produits"
Question
How can I disable this behaviour?
Django translations are not meant for dynamic data translations that come from third party data sources like your db. It is meant to translate the static stuff you have in your codebase.
You may want to use something like: https://django-modeltranslation.readthedocs.io/en/latest/ instead.
I have extensively used gettext system in my c++ application in linux environment for translation into different languages. Everything works fine.
Now, suppose that the whole application has been translated to English from German. But I need to query on some strings which should be in German (meaning query on the original string).
Like gettext("Energie") --> this is in German and translates to "Energy" in English and user can see that but I need the string "Energie".
There could be many solutions but I am specifically looking into gettext system. Is there way in gettext system to retrieve the original text ? Any help is appreciated.
Reverse translation like this isn't possible with gettext. Here's a simple .PO file for French:
msgid "a strawberry"
msgstr "une fraise"
msgid "a drill"
msgstr "une fraise"
You cannot reverse-translate "une fraise" back into English, as there are two possible meanings, and gettext would not know which one you meant.
Maybe you need what the Python gettext documentation calls "deferred translation": Instead of applying the translation function at definition time, rather do it at print time.
Instead of this, which will use different array indices in each language:
name = _('Energie')
dict[name] = 50
print('%s is %d' % (name, dict[name]))
do this:
name = 'Energie'
dict[name] = 50
print('%s is %d' % (_(name), dict[name]))
(Assuming that _() is used as a real translation function; this won't work if it's a preprocessor directive as I read it's often the case in C environment.)
This is the first time I used Django localization.
I generated the .po files with makemessages and randomly select a
few strings to fill in the translations, just to check if
localization works.
Then I generate the .mo file with
compilemessages.
I go to the web page and only see a string
'Username' translated, most other strings don't get the translated
version displayed.
What is going on here?
EDIT:
I found out why 'Username' is translated, it used the default translation in Django, but why Django didn't use my mo file is beyond me. I followed all the instructions in i18n doc.
I set the LOCALE_PATHS variable in settings.py to the path for my localization files.
I tried different LANGUAGE_CODE settings 'zh-cn', 'zh_CN'(both the setting variable and the directory name).
I tried msgunfmt django.mo, the file is valid.
There are some lines close to the beginning of po file:
#, fuzzy
msgid ""
msgstr ""
I believe this is normal.
I finally got it working after hours of trial and error.
I change my LOCALE_PATHS from:
LOCALE_PATHS = ("/path/to/locale/");
to:
LOCALE_PATHS = ("", "/path/to/locale/");
And it works right away. Maybe it is a bug with Django 1.5 (which I am using), or maybe I configured something wrong.
Anyway, hope this helps someone, and save you hours of time.
=========EDIT===========
As pointed out by #J.C.Leitão, you have to add comma to make the variable a tuple.
It was a rookie mistake of mine. But I think Django could be more friendly to developers if a single string is recognized, too.
I have installed the django-rosetta for translation, made .po and .mo files through django command
django-admin.py makemessages -l ar
and translate all words through django-rosetta,
now when i change my language to Arabic from English, it show some words in Arabic and some in English, although i have translated all these words in Arabic,
Have you restarted you web server?
This means your project's labels will be translated right away, unfortunately you'll still have to restart the webserver for the changes to take effect. (NEW: if your webserver supports it, you can force auto-reloading of the translated catalog whenever a change was saved. See the note regarding the ROSETTA_WSGI_AUTO_RELOAD variable in conf/settings.py.
-- http://code.google.com/p/django-rosetta/
What kind of server are you running?
I had the same problem with Apache2 and FastCGI. I had to restart the FastCGI Process to see the modifications.
Have you added the local path properly to your settings?
PROJECT_PATH = os.path.split(os.path.abspath(os.path.dirname(__file__)))[0]
LOCALE_PATHS = (
os.path.join(PROJECT_PATH, "locale"),
)
Do you have translations marked as fuzzy? (In Rosetta you can filter to display only fuzzy translations.) If some strings are fuzzy, make sure they are properly translated, uncheck the fuzzy flag and save the translations.
Another reason for translations not showing up could be that some python formatting strings (e.g. 'My %s apple') are not properly reproduced in the translated string. If formatting codes are unbalanced Rosetta should warn you, and the actual translation doesn't get written to the file.
I have a problem with django translations.
Problem 1 - I updated string in django.po file, but the change does not appear on the webpage.
Problem 2 - I have created my own locale file with django-admin.py makemessages -l et, added the translation string into file, but they too do not appear on the page.
I do not think this is setting problem, because the translations from django.po file do appear on the website, its just the changes and the translations from my own generated file that do not appear.
Edit:
My settings.py contains this:
gettext = lambda s: s
LANGUAGE_CODE = 'et'
LANGUAGES = (
('et', gettext('Estonian')),
)
my own locale files are in
/path/to/project/locale/et/LC_MESSAGES/
and the files are
django.mo and django.po
the file I refer to in problem 1 is django own et transaltion, which I changed.
Well, I got this same error a few moments ago. I solved it deleting the "#, fuzzy" tag over the translation strings in my django.po files. It seems that translated text is not served if it got this tag, so make sure to translate the text and then delete this line.
Here is an example of a translated text not server on a po file:
#: course/models.py:13
#, fuzzy
msgid "code"
msgstr "código"
So, just delete the flag and leave it like this:
#: course/models.py:13
msgid "code"
msgstr "código"
I hope this work for you. Good luck!
Reference: http://share-experiences.com/blog/what-fuzzy-means-python-django-gettext/
PD: I know you got this issue a few month ago, but I leave this response due that you we never heard if you got this problem solved.
Had a same/similar issue with translations not showing up. Setting the LOCALE_PATHS fixed the issue:
# settings.py
USE_I18N = True
USE_L10N = True
LOCALE_PATHS = (
'/path/to/djangoapp/locale',
)
Translation files (PO) are loaded in memory only one time, changes to the PO files are not picked up by Django. In order to load the new translation files you need to restart Django (eg. stop/start runserver, Apache or NGINX).
One additional reason for Django translations not working is to compile the .po file with a Python version different than the one being used to run your application. Make sure you use the same version.
Make sure to use ugettext_lazy and not ugettext
If you are using gettext.translation to get the translations, i.e:
text_de = gettext.translation('django', locale_dir, ['de'], fallback=True).ugettext('Welcome to my site')
... and your translation works on the development server but not on production, note that locale_dir must point to your locale directory. It might be located elsewhere on one of the systems. Spent like 2 hrs finding it.
Check for the USE_I18N setting. More info. Anyway, I think by default it's True...