Django i18n: makemessages only on site level possible? - django

I have several strings in my site that don't belong to any app, for example
{% block title %}{% trans "Login" %}{% endblock %}
or a modified authentication form used to set the locale cookie
class AuthenticationFormWithLocaleOption(AuthenticationForm):
locale = forms.ChoiceField(choices = settings.LANGUAGES,
required = False,
initial = preselectedLocale,
label = _("Locale/language"))
Now when I execute django-admin.py makemessages --all -e .html,.template in the site directory, it extracts the strings from all Python, .html and .template files, including those in my apps. That is because I develop my apps inside that directory:
Directory structure:
sitename
myapp1
myapp2
Is there any way to extract all strings that are not in my apps?
The only solution I found is to move the app directories outside the site directory structure, but I'm using bzr-externals (similar to git submodules or svn externals) so that doesn't make sense in my case.
Moving stuff that needs translation into a new app is also possible but I don't know if that is the only reasonable solution.

According to the documentation you could run makemessages from the app you like to translate, creating only the message files for that specific app. It is also possible to filter out some specific folders by using makemessages' --ignore argument. The results between those two would be quite different, though.

Related

How to setup email translation with Django Allauth

I am trying to setup translations for emails with django-allauth.
I have rewritten my templates, translated my .po files and complied them.
The html translations work fine but for some reason just the emails don't get translated.
I have properly configured translations following the django tutorial
https://docs.djangoproject.com/en/1.10/topics/i18n/translation/#how-django-discovers-language-preference
The related question doesn't help:
How does email translation work with django allauth?
Package versions:
Django==1.10
django-allauth==0.27.0
I had the same problem with django-allauth==0.32.0 and Django==1.11.1. Translations that are shipped with allauth are simply outdated or incomplete. In my project, for example, an email with a link to reset the password was always in English (in default language LANGUAGE_CODE = 'en') although the user set the language to Czech.
In .po file for Czech translations: https://github.com/pennersr/django-allauth/blob/master/allauth/locale/cs/LC_MESSAGES/django.po#L408 is this e-mail translation marked as fuzzy – so translations are not used. The same applies to other languages I've checked (de, es...).
The reason is explained in this comment from the author of allauth:
The allauth templates are merely meant as a starting point, something
to get you going quickly. Hence, I do not treat issues in the
translations as blocking for release, which can result in translations
getting left behind. Feel free to submit pull requests to fill in the
gaps.
Source: https://github.com/pennersr/django-allauth/issues/1113#issuecomment-141189606
I think there are two ways to solve this issue:
Fix/update translations on https://www.transifex.com/django-allauth/django-allauth/, submit pull request on Github and wait for a new release.
My recommendation: copy all templates from allauth to your project, make your own *.po files and ignore all default translations/templates. Do not forget that e-mail templates are in *.txt so you must call makemessages this way: python manage.py makemessages ... --extension html,txt,py.

Flask-Assets not working at all... = Insanity

I have simply tried setting up flask-assets (based on webassets), however just can't get it to work.
I have the standard setup;
python virtualenv
pip to install the bare essentials (flask, flask-assets)
sass ruby gem (for trying sass / scss)
less via npm (for trying lesscss)
jsmin via pip (for trying jsmin)
Config:
I have created a working homepage in Flask
static folder created (for css / js assets)
The css / js files are confirmed working (css background, js slider, etc)
Basically my development non-flask-assets site is working perfectly
I have followed the easy official guide here: flask-assets usage.
I fully understand how to work with it (as per that page). I have even exact copy-pasted the code, & still can't get it working.
Some code I've tried (for lesscss): (of course I have working css in main.less)
from flask.ext.assets import Environment, Bundle
assets = Environment(app)
assets.debug = True
lesscss = Bundle('main.less', output='main.css', filters='less')
assets.register('less', lesscss)
Then in my template:
{% assets "less" %}
<link href="{{ ASSET_URL }}" rel="stylesheet">
{% endassets %}
However flask-assets just won't work. I've tried the same with sass, scss, & also jsmin (exact code copy-paste from the usage guide) - it still won't work.
I notice that the .webassets-cache folder is created, but is (always) empty...
Also; relevant error?; I expect it to create the main.css, but as it doesn't, I get an error in the browser (using app.debug = True & flask's built-in dev server):
webassets.exceptions.BuildError
BuildError: Nothing to build for <Bundle output=css/main.css, filters=[<webassets.filter.less.Less object at 0x7f4958dc6710>], contents=('css/main.less',)>, is empty
So; If I manually create an empty main.css, it loads the page (no error), however the main.css file is not filled with css so flask-assets / webassets in still not working.
I've also tried passing the assets object to the template in various ways just in case it's needed (although no documentation states this) - that didn't work.
It's been driving me crazy. Any pointers would be appreciated.
Thank you
There is info missing on the Flask-Assets docs.
You problem is either the sass_bin config or the enviroment load path.
You should try both, in my case it was the config. See below my working config.
PS: IMHO Flask Assets is neither very complete nor well documented. It also consumes you application runtime, which sucks both on debugging and production. I have switched to GULP!
env = Environment(app)
env.config['sass_bin'] = '/usr/local/bin/sass'
# env.load_path = [os.path.join(os.path.dirname(__file__), 'sass')]
js = Bundle('js/jquery/jquery-2.1.4.js', 'js/angular/angular.js',
'js/socketio/socket.io.js', filters='jsmin', output='js/all_min.js')
env.register('js_all', js)
myjs = Bundle('myjs/Interpolation.js', 'myjs/socketio.js' , filters='jsmin', output='myjs/all_min.js')
env.register('myjs_all', myjs)
css = Bundle('sass/base.sass', filters='sass', output='css/base.css')
env.register('css_all', css)

why my django groundwork doesn't work

I install django-groundwork by pip and set add 'groundwork' to the my django app but it seems doesn't work,I don't know why?When I use command 'python manage.py help' to check which command could be used ,there is no 'ground' but the module dose exist.Please give me some help
The groundwork pagkage doesn't provide any management commands. It only provides some templates and template tags. That's why you're not seeing anything when calling manage.py (or django-admin.py'
The docs say it clearly, but you can check out the code... there's simply no management/commands directory inside the installed package.
Groundwork is a small set of template tags and filters that simplifies
working with Zurb Foundation
To truly say that the application "doesn't work", you'd have to use the template tags it provides.
Do this in a template
{% load groundwork_tags %}
Then do this
{% groundwork_icon 'info' '5em' 'text-centered' %}
If that breaks your template, it means the app isn't properly installed, is broken, or otherwise there's something else wrong.
Read about django management commands a little, it will all be clear (make sure to read about the version of django that you have installed.. the link will always point to the development version so things might be different there):
https://docs.djangoproject.com/en/dev/howto/custom-management-commands/

Django I18n Translation of The whole document

when i start translating the django application.
{% trans 'Profilbild'%}
All other trans blocks with umlaut are not translated. What is the solution ?
Regards
That's not how it works, the i18n tag translates a string or variable, it only takes one argument. Did you read the documentation?
You probably want blocktrans
UPDATE (the OP changed the question):
Did you run makemessages -l <desired_lang> successfully
Did you run compilemessages successfully
Did you restart the Django process after these steps?

Cannot Extend Django 1.2.1 Admin Template

I am attempting to override/extend the header for the Django admin in version 1.2.1. However when I try to extend the admin template and simply change what I need documented here: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#overriding-vs-replacing-an-admin-template), I run into a recursion problem.
I have an index.html file in my project's templates/admin/ directory that starts with
{% extends "admin/index.html" %}
But it seems that this is referencing the local index file (a.k.a. itself) rather than the default Django copy. I want to extend the default Django template and simply change a few blocks. When I try this file, I get a recursion depth error.
How can I extend parts of the admin? Thanks.
SOLUTION: Rather than extending, I copied the files into my_templates_directory/admin/ and just edited them as I wished. This solution was acceptable, though not ideal.
The contrib/admin/templates/admin path needs to go before the directory with your custom admin templates in your list of paths in TEMPLATE_DIRS in your settings.py
Create a symlink to contrib/admin/templates/admin/ in your templates directory and use it in your {% extends %} statement.
cd /path/to/project/templates/
ln -s /path/to/django/contrib/admin/templates/admin/ django_admin
Now in your admin/index.html use {% extends "django_admin/index.html" %}
EDIT: Just realized that you're on windows... Not sure how to achieve the same results. Hopefully this still helps the folks on linux.
SOLUTION: Rather than extending, I copied the files into my_templates_directory/admin/ and just edited them as I wished. This solution was acceptable, though not ideal.