At first sorry for my English :).
LANGUAGE_CODE setting doesn't work correctly.
When I configured LANGUAGE_CODE="mn", but default language code is "en".
from django.utils.translation import get_language
print get_language()
>>> en
then I tried to configure LANGUAGES setting
LANGUAGES = (
("mn": "Mongolia"),
("en": "English"),
)
but still "en"
changed LANGUAGES setting
LANGUAGES = (
("mn": "Mongolia"),
("en-us": "English"),
)
now it is "mn"
but want above settings
LANGUAGE_CODE = "mn"
LANGUAGES = (
("mn": "Mongolia"),
("en": "English"),
)
It doesn't work correctly. Is it BUG ? or something else?
I also tried creating "mn", "en" locale.
Hope help me. Thanks.
If you haven't already, be sure to read this specific topic in the Django documentation:
How Django discovers language preference
https://docs.djangoproject.com/en/1.3/topics/i18n/deployment/#how-django-discovers-language-preference
We're not using Django 1.3 yet, but we are using Django with multiple languages.
The first item to check is to verify the Accept-Language HTTP header being sent by your browser. Use Fiddler or Charles Proxy or similar tool to verify. Sounds like your browser may be sending "en-us" as a language preference.
In your settings file, make sure USE_L10N and USE_I18N are set to True.
https://docs.djangoproject.com/en/dev/ref/settings/#use-i18n
https://docs.djangoproject.com/en/dev/ref/settings/#use-l10n
Related
I'm Korean and using django-all-auth in my Django Project.
I checked that there is Korean .po file in django-all-auth.
But all expressions are english, not Korean.
I just followed Installation part and Configuration part in doc.
And here is my settings.py
LANGUAGE_CODE = 'ko-kr'
TIME_ZONE = 'Asia/Seoul'
USE_I18N = True
USE_L10N = True
USE_TZ = True
Did I miss something?
You need to activate the internationalization middleware:
In your settings.py set:
MIDDLEWARE = {...,"django.middleware.locale.LocaleMiddleware",...}
As said in the Doc
Make sure you’ve activated translation for your project (the fastest
way is to check if MIDDLEWARE includes
django.middleware.locale.LocaleMiddleware). If you haven’t yet, see
How Django discovers language preference.
Since now your pages are configured to route to the desired internationalization you now need to provide localization yourself. They will not automatically be translated. You need to handle it yourself.
To do so you will have to mark the elements that need to be translated by using
from django.utils.translation import ugettext as _
Now mark the text that you need to translate by using ugettext as _in the following way:-
class PollPluginPublisher(CMSPluginBase):
model = PollPluginModel # model where plugin data are saved
module = _("Polls")
name = _("Poll Plugin") # name of the plugin in the interface
Now the elements are marked to be translated in our case ("Polls") and ("Poll Plugin").
After dealing with this you can run following command in your root directory:-
django-admin makemessages -l de
Replace the last "de" with your language locale name. What this command does is that it will create the po file which will just store the elements that need to be translated. Be sure that your LOCALE_PATH is set properly.
After this done you can use the following django-packages for translations:-
1) django-rosetta :- https://django-rosetta.readthedocs.io/en/latest/
2) django-modeltranslation:- http://django-modeltranslation.readthedocs.io/en/latest/
For further reference of LOCALIZATION you can view:-
https://docs.djangoproject.com/en/1.10/topics/i18n/translation/#localization-how-to-create-language-files
We're developing an application which will serve multiple industries. I'm hoping to use django's i18n functionality to accomplish two things:
Translation to different languages (standard).
Translation to different industries (much less standard).
Lets say the application serves vets and car mechanics, you would end up with a matrix of options:
| English | French
----------------------------------
Vets | horse | cheval
----------------------------------
Car Mechanics | car | voiture
I guess I can setup the message files for different contexts pretty easily:
python manage.py makemessages -l fr_vet
etc...
Now how would I go about activating that translation?
I know the industry in middlewhere from the request, could I subclass django.middleware.locale.LocaleMiddleware and alter it, or do I need to subclass django.utils.translation and alter the activate function? Or something completely different?
Appologies if I've missed an existing explanation of how to do this - it was a classic case of "I'm sure the answer must exist but without knowing what it's called I can't google it".
I had the same situation once and I read almost all Django documentation about translations (it's really huge)... I would like to share with you some important links that can help:
Switch language in templates:
https://docs.djangoproject.com/en/dev/topics/i18n/translation/#switching-language-in-templates
This one, I think is the most important one for you, "How django discovers language..."
https://docs.djangoproject.com/en/dev/topics/i18n/translation/#how-django-discovers-language-preference
One of the things that I think you are missing are the languages in your settings file, for example:
LANGUAGES = (
('de', _('German')),
('en', _('English')),
)
Lara's answer was useful, but didn't explain it fully, I thought it worthwhile to add a full explanation.
All that's required is to add middleware which sets the translation code for the industry:
from django.middleware.locale import LocaleMiddleware
from django.utils import translation
class CustomLocaleMiddleware(LocaleMiddleware):
def process_request(self, request):
check_path = self.is_language_prefix_patterns_used()
language = translation.get_language_from_request(
request, check_path=check_path)
if hasattr(request, 'user_info'):
language = language[:2] + '-' + request.user_info['trans_code']
translation.activate(language)
request.LANGUAGE_CODE = translation.get_language()
(Note: user_info is added to request in middleware which is called before CustomLocaleMiddleware)
request.user_info['trans_code'] will be set to "ve" for vets and "cm" for car mechanics.
Then in settings:
MIDDLEWARE_CLASSES = (
...
'path.to.middleware.CustomAuthMiddleware', # this adds request.user_info
'path.to.middleware.CustomLocaleMiddleware',
...
)
LANGUAGE_CODE = 'en'
USE_I18N = True
USE_L10N = True
LANGUAGES = (
('en-ve', 'English Vets'),
('en-cm', 'English Car Mechanics'),
('fr-ve', 'French Vets'),
('fr-cm', 'French Car Mechanics'),
)
LOCALE_PATHS = (os.path.join(BASE_DIR,'locale'),)
You can create your .po files with
python manage.py makemessages -l en_VE -l en_CM -l fr_VE -l fr_CM
This has the advantage that it would default to the standard "de" translation if you had it but hadn't yet build "de-ve" or "de-cm".
I'm trying to use django-tinymce to edit fields in django admin.
I've the app installed in my virtualenv (django-tinymce==1.5.1b4). It's listed in my installed apps -
INSTALLED_APPS = (
#...
'tinymce',
#...
)
My settings includes the following
TINYMCE_DEFAULT_CONFIG = {
'theme': "advanced",
'theme_advanced_toolbar_location': "top",
'theme_advanced_buttons1': "bold,italic,underline,separator,"
"bullist,separator,outdent,indent,separator,undo,redo",
'theme_advanced_buttons2': "",
'theme_advanced_buttons3': "",
}
TINYMCE_SPELLCHECKER = True
TINYMCE_COMPRESSOR = True
And I've got the files available at /MEDIA_ROOT/js/tiny_mce (the default).
My models look like -
from tinymce import models as tinymce_models
class MyModel(models.Model)
post = tinymce_models.HTMLField()
When I go to the model admin page, the field appears as a normal text field and my browser tells me there's an error on the inline js script for the field. It says it doesn't recognise the variable tinyMCE. It doesn't look like the page is even trying to load the js file (I'm getting no 404's - I can't see any sign of anything being loaded).
I'm not sure what I'm missing..
Have You, Sir, done python manage.py collectstatic ?
What value variable in settings.py is in TINYMCE_JS_ROOT and TINYMCE_JS_URL
If variable TINYMCE_JS_URL is not set check if You, Sir, have file at /MEDIA_ROOT/js/tiny_mce/tiny_mce.js. If not, try to copy manually from django-tinymce's egg.
OK, looks like it might have been a bug in the django_tinymce code. I've reverted to 1.5.1b2 and everything works as expected. Guess I should look into filing a bug report.
Is there any braindead simple way to select the language specific version of a page on a Django website based on the domain? (the URLs are and will be the same for both languages, except the language code, so I want to have mysite.com/teachers/manage same as mysite.com/en/teachers/manage (done with 'en' default) and mesito.es/teachers to be same as mesito.es/es/teachers - and no, the urls themselves like 'teachers/manage' will never be translated, so I don't want to configure 2 sets of urls for both languages).
Note: All other solutions I've found imply that I also want to translate the URLs, but I know I will never want to translate the URLs and manae 2 sets of them for this particular website.
Note 2 (forgot to add): Most of the website is actually django-cms based, so django-cms specific solutions would be helpful to...
OK, I got what I wanted with this ugly hack through a redirecting view (but still, isn't there a right AND simple way to do this?...):
## mysite.urls:
urlpatterns = patterns('',
(r'^$', 'mysite.views.language_router')
## mysite.views:
def language_router(request):
if request.META['HTTP_HOST'].find('myspanishdomain.com') != -1 \
and request.META['PATH_INFO'] == '/' :
return HttpResponseRedirect('http://www.myspanishdomain.com/es/')
return cms.views.details(request, '')
(site at myenglishdomain.com has the default language english)
Why don't you write your onw tiny middleware class that you add after the LocaleMiddleware, that simply adds the language, if no language has been identified yet based on the rules that you have explained here in that thread.
You may want to have a look at Transurlvania as it allows you to map a domain to a language:
MULTILANG_LANGUAGE_DOMAINS = {
'en': ('www.example-en.com', 'English Site'),
'fr': ('www.example-fr.com', 'French Site')
}
You could use a separate site for each domain, and use a view mixin or a middleware to check the site id and react appropriately.
Right away: yes I know about INTERNAL_IPS.
I'm about to have my django app opened up at work integration and testing. I know there will be debugging and plenty modifications and/or optimizations to be made so I'd love to have the Django Debug Toolbar. However, I'd prefer to not have it up for all of my co-workers (who are the 'clients').
The reason the INTERNAL_IP setting doens't work for just me (btw: I have a static IP on my development computer) is that I am using Nginx as a reverse-proxy and serving with Gunicorn. Because of the reverse-proxy, using an internal_ip of 127.0.0.1 shows DjDT to any computer on the network and using that ip is the only way I've been able to see it myself.
What I'm looking for is either a way to get my IP or my login name to be the only one to access the toolbar. I once saw a thread about the user name limited access but I can't find it...
And as a side question- anyone know why the toolbar doesn't render in IE? For me it just shows as tables on the bottom of the page.
Try:
def show_toolbar(request):
return not request.is_ajax() and request.user and request.user.username == "yourusername"
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': 'projectname.settings.show_toolbar',
# Rest of config
}
The accepted answer is no longer correct. Newer versions of the toolbar need the value of the SHOW_TOOLBAR_CALLBACK key to be a string with the full import path of the function. So if you're defining your callback function your settings.py file, you'd have to add:
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': 'projectname.settings.show_toolbar',
}
If you face No .rsplit() Error. NEW SOLUTION:
Because SHOW_TOOLBAR_CALLBACK is now a dotted string path and not support a callable.
edit your settings.py:
def custom_show_toolbar(request):
return True # Always show toolbar, for example purposes only.
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': 'your_project_name.settings.custom_show_toolbar',
}
In Django 4+ this username validation worked for me:
def show_toolbar(request):
return str(request.user) == "username" #... any other validations