I am using the concept of multiple languages in my app and for that I have done all those things which are written in the doc.
But when I creates a locale file inside my project and then the respective language folder "es" and thus a by default django.po file is created which contains all the lines which I can edit .
e.g.
#: customer_reg/my_new_env/lib/python2.6/site-packages/django/conf/global_settings.py:48
msgid "Arabic"
msgstr ""
But this django.po file does not contain my app templates files which I can edit.
As i said I have created this locale file inside my project parallel to my app,I don't know why it happens.
So I have to create this inside my app parallel to my models and views ?? OR there is any another problem ??
Create the locale directory in your app, at the same level where your settings.py file exists.
Now from the previous level i.e. where you created the locale directory, type the cmd to generate a source file[.po].
cmd like ./manage.py makemessages -l [language code]
Check the language code from http://translate.sourceforge.net/wiki/l10n/pluralforms
Tada..!
this should work for you, will incude your app templates.
Let me know if this doesnt work for u.
Related
I'm working with a current project that has existing .po files in "locale" directories in multiple installed app directories. Currently each locale directory is explicitly mentioned in the LOCALE_PATHS even though the docs state it will search for locale directories in each installed app. I wanted to remove the values in LOCALE_PATHS and just let normal discovery work, but it's not working.
If I clear out LOCALE_PATHS and run manage.py makemessages it appears like it's doing something (time is spent processing), but no file changes occur. If I do makemessages --keep-pot then I can see all the .pot files are actually being created, but it's not actually creating the .po files for each language. Only if I explicitly pass a -l de I then get an updated .po file for the language stated and a message stating "processing locale de". It SHOULD be able to look at the LANGUAGES setting or what files already exist and properly update them, but that appears to only happen if every locale directory is explicitly added into LOCALE_PATHS. If I have all the locale paths in LOCALE_PATHS then I can just run manage.py makemessages and all .po files are properly updated.
This is on Django 3.0
UPDATE: I upgraded to Django 3.2 LTS and still have the same issue except now I must add -a to makemessages or it does nothing. Previously it seemed to assume a -a if not provided.
I'm running Vim 8.0.124 and I've installed the vim-snipmate plugin to use in my Python and Django development. I followed the instructions by creating a .vimrc file that contains the following:
# ~/.vimrc
set nocompatible " Required by Vundle
filetype off " Required by Vundle
" Begin Vundle settings ==========================================================
"
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
Plugin 'VundleVim/Vundle.vim'
Plugin 'MarcWeber/vim-addon-mw-utils'
Plugin 'tomtom/tlib_vim'
Plugin 'garbas/vim-snipmate'
# Optional
Plugin 'SirVer/ultisnips'
Plugin 'honza/vim-snippets'
call vundle#end()
filetype plugin indent on
"
" End Vundle settings ==========================================================
" SnipMate
autocmd FileType python set ft=python.django
autocmd FileType html set ft=htmldjango.html
" UltiSnips
let g:UltiSnipsExpandTrigger="<tab>"
let g:UltiSnipsJumpForwardTrigger="<c-b>"
let g:UltiSnipsJumpBackwardTrigger="<c-z>"
let g:UltiSnipsEditSplit="vertical"
Installing vim-snipmate includes the creation of these four files:
~/.vim/bundle/vim-snippets/snippets/django.snippets
~/.vim/bundle/vim-snippets/snippets/htmldjango.snippets
~/.vim/bundle/vim-snippets/UltiSnips/django.snippets
~/.vim/bundle/vim-snippets/UltiSnips/htmldjango.snippets
I have two questions. First, why are the UltiSnip Django snippets not working? The snippets in snippets/django.snippets work but those in the UltiSnips django.snippets file don't. If I open a file test.py and type "fdate" where fdate should expand into a Django DateField, nothing happens (other than a tab is entered). Initially, when the UltiSnips weren't working, I went to its Github page and read the instructions which seemed to indicate I should add the SirVer plugin so I did. Even then, then don't seem to work. I should add that what you see above is my entire .vimrc file. Also, I created a completely new ~/.vim directory which only contains the Vundle and vim-snipmate bundles so there shouldn't be any other conflicts.
My second less important question is, when I view any of these snippet files, most of the lines are folded. Is there any way I can configure Vim so that when I open any of these .snippet files, all the folds will be open? They would be easier to search that way.
Did you try with ":setfiletype htmldjango" ? or ":selfiletype django" (https://www.vim.org/scripts/script.php?script_id=1487)
Take a look in the docs, especially under section 4.1.1 How snippets are loaded UltiSnips-how-snippets-are-loaded
I had similar issue, I've created separate directory for snippets, at $HOME/UltiSnips. There I've created directory python, where I've moved files python.snippet and django.snippet. Similarly, you may create directories for another languages and use snippets for another frameworks.
From the docs:
UltiSnips iterates
over the snippet definition directories looking for files with names of the
following patterns: ft.snippets, ft_.snippets, or ft/, where "ft" is the
'filetype' of the current document and "*" is a shell-like wildcard matching
any string including the empty string.
I have a python script that queries customer and order information for a database, creates a latex template based on that data with jinja2, and finally calls
subprocess.call(['/usr/texbin/pdflatex', filename], shell = False)
with filename being the latex template.
The folder of the respective filename is named after the customer. I'm operating in Germany, so some of the filenames contain 'Umlaute' such as ö.
I have a folder structure like so:
.
└── invoices
├── customer_no_umlaut
├── invoice_no_umlaut_01
└── invoice_no_umlaut_02
└── cüstömer_with_ümläüt
├── invoice_with_ümlaut_01
└── invoice_with_ümlaut_02
This all works perfectly fine on my local computer.
Since I need to share these files, however, I want to have the pdfs in a Dropbox folder.
So in my code, I plug in the path to the Dropbox folder instead of the original local folder.
What I then get is the latex template in my Dropbox-folder with this text in parenthesis after the filename:
Unicode Encoding Conflict
as in
"Rechnung_Gedöns_4-724_(Unicode-Codierungskonflikt).tex"
So it seems that Dropbox is not happy with my unicode charset.
What I find strange, though, is that this applies to the filename only. The python script is able to create folders in the Dropbox with the customer's name retrieved from the database with the same encoding.
Does someone have any thoughts on how to solve this?
I managed to resolve this by chance more or less.
In my desperation, I deleted the customer folders containing an umlaut in my Dropbox. I then reran the script described in the question again. From the respective customer data, the script creates the path of the target file folder. If the folder does not exist, it is being created.
As I had deleted the folders, they were now created anew. The latex templates where then placed inside and called with
subprocess.call(['/usr/texbin/pdflatex', filename], shell = False)
And everything works fine.
I guess the old versions of the folders must have been where the unicode conflict took place.
I can switch languages in my Django application by changing LANGUAGE_CODE in the Settings.py file for the application.
But I'm not sure where the actual text is coming from.
In path-to-django/contrib/auth/locale/, there are directories for many languages containing the translations of the text I'm displaying. But if I move an .mo file for a particular language to a new name, I still see text for that language -- even after I restart Django. So where does the text actually come from?
Also, for the 'en' locale, the translated text is always "" (empty string). Does ugettext_lazy just return its input string in that case? If not, where does the English text come from?
It is a difference, if you speak of translation in the django admin or within your application. The path you mentioned .../contrib/auth/locale refers to translations in the django admin.
For special translation within your application you should have a locale/ folder in your project. This folder is created when you run the django special script named "django-admin.py makemessages".
The script runs over your project source tree or your application
source tree and pulls out all strings marked for translation. It
creates (or updates) a message file in the directory
locale/LANG/LC_MESSAGES. In the de example, the file will be
locale/de/LC_MESSAGES/django.po.
For detailed explanation, please look at django i18n documentation
After you have created your message files (*.po) and after you have written your own translations in the message files, don't forget to compile them:
Compiling message files
After you create your message file -- and each
time you make changes to it -- you'll need to compile it into a more
efficient form, for use by gettext. Do this with the django-admin.py
compilemessages utility.
This tool runs over all available .po files and creates .mo files,
which are binary files optimized for use by gettext. In the same
directory from which you ran django-admin.py makemessages, run
django-admin.py compilemessages like this:
django-admin.py compilemessages
That's it. Your translations are ready for use.
It turns out there was a system-wide Django installation that was being used, rather than my local installation.
By creating a locale directory within my app, I'm able to override the strings used in the system-wide installation. I just modify the .po file there, and compile it.
I'm running django-admin.py makemessages -l es from within my app directory to create trnaslation strings. The result includes only those texts that are located in my app directory. My templates directory to that app is located outside the app's directory. How do I ask django to translate my template files too?
I didn't want to run the above command from within the project's dir, because my project contains certain folders that I do not want to translate.
Never mind, I found the answer. You have to create symlinks to the folders you want to get translated (i.e. templaets) and copy those symlinks to you apps directory and run the above command with --symlinks included.
If i understand correctly you'll need to use django's trans and blocktrans
template tags to translate certain strings of text.