When I run manage.py makemessages I found some messages which were in the .po file like this:
msgid "Example"
msgstr "Example"
Transformed to this, after I ran the command:
#~ msgid "Example"
#~ msgstr "Example"
What does #~ means? Since the translation of those messages doesn't work anymore, I suppose it is a comment.
What can I do to prevent Django commenting out (or "#~ing") pre-existing messages in the translation file?
Django will comment-out all messages that are no longer in your code. It won't remove them, so you won't lose it, but that way this messages won't end up in compiled .mo file.
I was facing a similar problem with 3rd party apps. makemessages did not include them in the .po file and when adding them manually makemessages was commenting them out next time.
In my case I had the virtual env symlinked into the project folder. To make makemessages see those 3rd party apps I had to add -s
./manage.py makemessages -a -s -l de -i faker -i openid -i gunicorn
At the same time I want to exclude some apps from translations with -i
Related
I'm getting an odd error when I make the i18n files of a django project:
(venv) user#machine:~/path/to/repo$ django-admin makemessages -l es
It creates fake .py files for every .txt files:
For example, requirements/base.txt
Django==1.10.6
django-environ==0.4.1
djangorestframework==3.6
psycopg2==2.7
djangorestframework-jwt==1.9.0
Markdown==2.6.8
unipath==1.1
It generates a requirements.base.txt.py with 'XXXXXX' in it:
XXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX
XXXXXXXXXXXX
But it also creates the right .po files into /locale
Could you please point me in the right direction? Because I'm lost. Thank you!
For everyone that is having the same problem, this can also occur if you haven't created a locale/ folder within each app of your Django project, as it's the default folder if none specified in your settings.
After creating it, my problem went away.
More info in the documentation
The answer is here : Permission denied in Django makemessages
To make a long story short: makemessages misbehaves because it doesn't know your project's settings. Actually this should be reported as a defect (if it hasn't already) since most other commands that needs the settings to properly work detect the fact and do raise an ImproperlyConfigured error with an explicit message.
I've written a Django app, and now I want to make it easy to deploy on multiple servers.
The basic installation is:
Copy the app folder into the Django project folder
Add it to INSTALLED_APPS in settings.py
Run ./manage.py collectstatic
This particular app doesn't need to use the DB, but if it did, I'd use south and run ./manage.py migrate, but that's another story.
The part I'm having trouble with is #2. I don't want to have to manually edit this file every time. What's the easiest/most robust way to update that?
I was thinking I could use the inspect module to find the variable and then somehow append it, but I'm not having any luck. inspect.getsourcelines won't find variables.
You can modify your settings.py using bash.
#set $SETTINGS_FILE variable to full path of the your django project settings.py file
SETTINGS_FILE="/path/to/your/django/project/settings.py"
# checks that app $1 is in the django project settings file
is_app_in_django_settings() {
# checking that django project settings file exists
if [ ! -f $SETTINGS_FILE ]; then
echo "Error: The django project settings file '$SETTINGS_FILE' does not exist"
exit 1
fi
cat $SETTINGS_FILE | grep -Pzo "INSTALLED_APPS\s?=\s?\[[\s\w\.,']*$1[\s\w\.,']*\]\n?" > /dev/null 2>&1
# now $?=0 if app is in settings file
# $? not 0 otherwise
}
# adds app $1 to the django project settings
add_app2django_settings() {
is_app_in_django_settings $1
if [ $? -ne 0 ]; then
echo "Info. The app '$1' is not in the django project settings file '$SETTINGS_FILE'. Adding."
sed -i -e '1h;2,$H;$!d;g' -re "s/(INSTALLED_APPS\s?=\s?\[[\n '._a-zA-Z,]*)/\1 '$1',\n/g" $SETTINGS_FILE
# checking that app $1 successfully added to django project settings file
is_app_in_django_settings $1
if [ $? -ne 0 ]; then
echo "Error. Could not add the app '$1' to the django project settings file '$SETTINGS_FILE'. Add it manually, then run this script again."
exit 1
else
echo "Info. The app '$1' was successfully added to the django settings file '$SETTINGS_FILE'."
fi
else
echo "Info. The app '$1' is already in the django project settings file '$SETTINGS_FILE'"
fi
}
Use:
add_app2django_settings "my_app"
Here are my reasons why I think this would be wrong:
it is extra code complexity without any big need, adding one line to settings every time is not that bad, especially if you are doing step #1 and #3.
it will become not explicit what apps your project is using. When another developer will work on your project, he might not know that your app is installed.
you should do step #1 and step #2 on code versioning system, test the whole system and then commit the changes and just then deploy it.
I think you have something wrong (from my point of view) in your develop/deploy process if you are looking for such an "optimization". I think it is much easier and better to use INSTALLED_APPS.
If you are building something for public use and you want to make it as easy as possible to add modules then it would be nice. In this case I would recommend to package project and it's apps as python eggs and make use of entry points. Then you could deploy an app into project like this:
pip install my-app-name
Without even step #1 and #3! Step #1 will be done by pip, and step #2 and #3 will be done by setup hooks defined in your project.
Paste script is a good example of entry-points utilization:
# Install paste script:
pip install pastescript
# install django templates for pastescript:
pip install fez.djangoskel
# now paste script knows about fez.djangoskel because of entry-points
# start a new django project from fez's templates:
paste create -t django_buildout
Here is a portion of setup.py from fez.djangoskel package:
...
entry_points="""
[paste.paster_create_template]
django_buildout=fez.djangoskel.pastertemplates:DjangoBuildoutTemplate
django_app=fez.djangoskel.pastertemplates:DjangoAppTemplate
...
zc.buildout is another great tool which might make your deployments much easier. Python eggs plays very nice with buildout.
I have my translation strings only in templates (stored in the project_dir/Templates), I tried running the $ django-admin.py createmessages -l ru both in the project root directory and in the app directories that use templates with trans. strings. It created folders locale/ru/LC_MESSAGES but the folders were empty. I tried to add the django.po files manually (with the syntax mentioned in the l10n docs). And ran the createmessages -a and compilemessages commands. It created the .mo files, but the translations didn't appear in the browser.
As I created the .po files manually I had no lines starting with #. What should I write there?
My template files are in different folder than the .py files for apps. Should I put some extra links to them?
did you try :
python manage.py makemessages -a
from project root and app ?
this should create a .po that you have to edit.
be sure to remove 'fuzzy' stuff everywhere.
then :
python manage.py compilemessages
You need to restart the server
For newer versions of Django (e.g. 3.2):
in the root directory create folder "locale"
run command django-admin makemessages -l ru
update your language files (located in the locale folder)
run django-admin compilemessages
Configure the LOCALE_PATHS in settings.py, otherwise you won't see the translations:
LOCALE_PATHS = [os.path.join(BASE_DIR, 'locale')]
LANGUAGE_CODE = 'ru'
To fix empty po files:
Make sure you did the needed changes for the templates as mentioned in the documentation. Please make sure that you are checking the correct documentation version for your project.
You can add a locale directory in your templates directory and add its path to the LOCALE_PATHS list. (Optional, but helpful to make sure that the template directory is included in step 4)
Go to the project_dir (you should run the next command in a parent directory of the files to be translated)
Run the command django-admin makemessages -l ru
How would you go about internationalizing a Google App Engine webapp application using BABEL? I am looking here for all the stages:
Marking the strings to be translated.
Extracting them.
Traslating
Configuring your app to load the right language requested by the browser
1) use _() (or gettext()) in your code and templates. Translated strings set in the module globals or class definitions should use some form of lazy gettext(), because i18n won't be available when the modules are imported.
2) Extract all translations using pybabel. Here we pass two directories to be scanned: the templates dir and the app dir. This will create a messages.pot file in the /locale directory with all strings found in these directories. babel.cfg is the extraction configuration that varies depending on the template engine you use:
$ pybabel extract -F ./babel.cfg -o ./locale/messages.pot ./templates/ ./app/
3) Initialize a directory for each language. This is done only once. Here we initialize three translations, en_US, es_ES and pt_BR, and use the messages.pot file created on step 2:
$ pybabel init -l en_US -d ./locale -i ./locale/messages.pot
$ pybabel init -l es_ES -d ./locale -i ./locale/messages.pot
$ pybabel init -l pt_BR -d ./locale -i ./locale/messages.pot
Translate the messages. They will be in .mo files in each translation directory.
After all locales are translated, compile them:
$ pybabel compile -f -d ./locale
Later, if new translations are added, repeat step 2 and update them using the new .pot file:
$ pybabel update -l pt_BR -d ./locale/ -i ./locale/messages.pot
Then translate the new strings and compile the translations again.
4) The strategy here may vary. For each request you must set the correct translations to be used, and probably want to cache loaded translations to reuse in subsequent requests.
print :
D:\zjm_code\register2>python D:\Python25\Lib\site-packages\django\bin\django-adm
in.py makemessages -l cn
Error: This script should be run from the Django SVN tree or your project or app
tree. If you did indeed run it from the SVN checkout or your project or applica
tion, maybe you are just missing the conf/locale (in the django tree) or locale
(for project and application) directory? It is not created automatically, you ha
ve to create it by hand if you want to enable i18n for your project or applicati
on.
2.i made a locale directory ,and
D:\zjm_code\register2>python D:\Python25\Lib\site-packages\django\bin\django-adm
in.py makemessages -l cn
processing language cn
Error: errors happened while running xgettext on __init__.py
'xgettext' 不是内部或外部命令，也不是可运行的程序
或批处理文件。
D:\Python25\lib\site-packages\django\core\management\base.py:234: RuntimeWarning
: tp_compare didn't return -1 or -2 for exception
sys.exit(1)
3.
ok
http://hi.baidu.com/zjm1126/blog/item/f28e09deced15353ccbf1a82.html
is register2 your project or app tree?
did you make directory register2\\locale?