Our project has translation files that exist in specific branches. Often when switching between branches, I receive the following error:
I18n::InvalidLocaleData
can not load translations from /.../config/locales/feature.yml: #<Errno::ENOENT: No such file or directory # rb_sysopen - /.../config/locales/feature.yml>
I can fix this by restarting the server, but I was wondering if there is a way to (in development) have rails watch the locales folder to check for added/removed files.
Related
I am packaging a Horizon Plugin. I have a bunch of templates, a view, as well as css, js files, and images.
Everything should be contained so that the package is either a .deb or a tarball. So right now I keep all files in /opt/stack/horizon/openstack_dashboard/dashboards/<my-dashboard-name>.
My question is, how do I include js and css files properly? There is /opt/stack/horizon/openstack_dashboard/settings.py file that specifies HORIZON_CONFIG.js_files, however it is always empty! I put a list of files there, it still comes out as empty in the templates. So the question is, how do I include js and css files in a Horizon dashboard plugin, for the purpose of packaging it in either a single tarball or a .deb package?
You should store static files below <my-dashboard-name>/static. It's best to namespace your static files, I use the following directory structure:
<my-dashboard-name>/static/<my-dashboard-name>/js and so on for css and img then I reference the files in the HTML templates with /static/<my-dashboard-name>/js/jsfile.js, that way you won't get any name collisions.
When someone uses your plugin they extract your dashboard and register it in the right places and then additionally they have to run the collectstatic django management command from the base openstack_dashboard directory (in your case /opt/stack/horizon/), either:
$ ./run_tests.sh -m collectstatic
or
$ ./manage.py collectstatic
That should copy your static files to the right places according to how the site has been configured.
I am severely confused about where to put my templates files and static files.
I understand absolute and relative paths just fine, but I can't seem to find any instructions that mirror the installation I have. I know this resembles other questions, but those answers aren't working. The video I watched to successfully build a simple app didn't put templates in the Project folder, which is where logic tells me they should be.
I have Python at:
C:\Python27
Django (v1.6.5) at:
C:\Python27\Lib\site-packages\django
I created a project "mysite" and an app called "films."
Project "mysite":
C:\Python27\Scripts\venv\mysite
and an App "films":
C:\Python27\Scripts\venv\mysite\films
The video I watched had me put my templates at:
C:\Python27\Lib\site-packages\django\contrib\admin\templates
But this seems completely stupid because the templates are outside of both the Project and the App.
Shouldn't I put a templates folder in the Project folder:
C:\Python27\Scripts\venv\mysite\templates
And then create subdirectories using the App name?
What files do I need to edit (and how) to tell Django where to find them?
Follow a similar process for static files (css, images)?
Like all frameworks, django offers great benefits if you follow some guidelines (and give up some control). The trick is to know what these guidelines are.
For templates:
If the template is not tied to a particular application, put it in a templates directory at the root of your project. Add the full path to this directory to TEMPLATE_DIRS.
All other templates should go in a directory called templates inside your application directory. So if you application is called myapp, templates for myapp will go in myapp/templates/
For static files:
For files related to specific applications, inside your application directory create a directory called static, then inside it a directory with the name of your application. So, if your application is called myapp, you would have myapp/static/myapp. Place all your static content for this application here; for example myapp/static/myapp/js/funky.js.
For static files that are generic, create a directory called assets (or static) in the root directory of your project. Add the full path to this directory to STATICFILES_DIRS.
By default, django will search all applications listed in INSTALLED_APPS, and add any templates and static directories to its search path for files. This is how, by default, the admin works without you having to configure anything.
If you chose to place your templates and static files in some other location, only then do you need to modify the TEMPLATE_DIRS and STATICFILES_DIRS settings. If all your templates and static assets are tied to applications, just creating the directories as mentioned above makes everything work.
If you are wondering why you need to create another directory under myapp/static/ to store your static files, this is more for portability. The collectstatic command is a simply "copy and replace" utility. It will overwrite all files in the STATIC_DIR location. This means that if two applications have some static file with the same name, they will be overwritten without warning. Adding a subdirectory keeps your application's static assets from being overwritten, because the exact path will be created.
Suppose you have two applications, app1 and app2, and both have a file named style.css in their respected directories:
app1/static/css/style.css
app2/static/css/style.css
When you run collectstatic, you'll end up with the following (assuming static is the name of your STATIC_DIR setting):
static/css/style.css
This may be the style.css from app1 or app2, the other cannot be determined (its actually based on the INSTALLED_APPS order). To prevent this, if you have:
app1/static/app1/css/style.css
app2/static/app2/css/style.css
Now, you'll end up with:
static/app1/css/style.css
static/app2/css/style.css
Both files will be preserved.
You also shouldn't put your code in your virtual environment directory. The virtual environment is not part of your source code, and placing your project in the same directory may cause problems later.
Create a single directory for your environments - I call mine envs (creative, I know). Create all your environments in this directory. Once you activate the environment, you can work in any directory in your system and your shell will be configured for that environment's Python.
Finally for the best, accurate, most up-to-date information - always refer to the django manual and the tutorial. Almost all other resources (even the often suggested djangobook.com) are outdated.
I was cleaning my Documents folder and renamed the folder containing all the python/html files for the application. I edited an HTML file, pushed to dotcloud, and the application is down. Does anyone know a why to fix this? I've already tried renaming the folder containing the files back to the original and pushing to dotcloud, but it failed.
Edit 1: I just tried pushing with older files from a previous computer, and it also failed. (This solution usually works, so is there something at dotcloud's end that changed?)
My application is here: www.hours.lambertnhs.com
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.
Here's the scenario:
I'm running Django 1.3.1, utilizing staticfiles, and django-compressor (latest stable) to, among other things, compile LESS files.
I have an "assets" directory that's hooked into staticfiles with STATICFILES_DIRS (for project-wide static resources). In that directory I have a "css" directory and in that a "lib.less" file that contains LESS variables and mixins.
So the physical path is <project_root>/assets/css/lib.less and it's served at /static/css/lib.less.
In one of my apps' static directory, I have another LESS file that needs to import the one above. The physical path for that is <project_root>/myapp/static/myapp/css/file.less and it would be served at /static/myapp/css/file.less.
My first thought was:
#import "../../css/lib.less"
(i.e. based on the URL, go up to levels from /static/myapp/css to /static/, then traverse down into /static/css/lib.less).
However, that doesn't work, and I've tried just about every combination of URLs and physical paths I can think of and all of them give me FilterErrors in the template, resulting from not being able to find the file to import.
Anyone have any ideas what the actual import path should be?
After tracking down exactly where the error was coming from in the django-compressor source. It turns out to be directly passed from the shell. Which clued me into removing all the variables and literally just trying to get the lessc compiler to parse the file.
Turns out it wants a relative path from the source file to the file to be imported in terms of the physical filesystem path. So I had to back all the way out to my <project_root> and then reference assets/css/lib.less from there. The actual import that finally worked was:
#import "../../../../assets/css/lib.less"
What's very odd though is that lessc would not accept an absolute filesystem path (i.e. /path/to/project/assets/css/lib.less). I'm not sure why.
UPDATE (02/08/2012)
Had a complete "DUH" moment when I finally pushed my code to my staging environment and ran collectstatic. The #import path I was using worked fine in development because that was the physical path to the file then, but once collectstatic has done it's thing, everything is moved around and relative to <project_root>/static/.
I toyed with the idea of using symbolic links to try to match up the pre and post-collectstatic #import paths, but I decided that that was far too complicated and fragile in the long run.
SO... I broke down and moved all the LESS files together under <project_root>/assets/css/, and rationalized moving the LESS files out of the apps because since they're tied to a project-level file in order to function, they're inherently project-level themselves.
I'm sort of in the same bind and this is what I've come up with for the most recent versions of compressor and lessc to integrate with staticfiles. Hopefully this will help some other people out
As far as I can tell from experimenting, lessc doesn't have a notion of absolute or relative paths. Rather, it seems to maintain a search path, which includes the current directory, the containing directory of the less file, and whatever you pass to it via --include-path
so in my configuration for compressor I put
COMPRESS_PRECOMPILERS = (
('text/less', 'lessc --include-path=%s {infile} {outfile}' % STATIC_ROOT),
)
Say, after running collectstatic I have bootstrap living at
STATIC_ROOT/bootstrap/3.2.0/bootstrap.css.
Then from any less file, I can now write
#import (less, reference) "/bootstrap/3.2.0/bootstrap.css"
which allows me to use the bootstrap classes as less mixins in any of my less files!
Every time I update a less file, I have to run collectstatic to aggregate them in a local directory so that compressor can give less the right source files to work on. Otherwise, compressor handles everything smoothly. You can also use collectstatic -l to symlink, which means you only need to collect the files when you add a new one.
I'm considering implementing a management command to smooth out the development process that either subclasses runserver to call collectstatic each time the server is reloaded, or uses django.utils.autoreload directly to call collectstatic when things are updated.
Edit (2014/12/01): My approach as outlined above requires a local static root. I was using remote storage with offline compression in my production environment, so deployment requires a couple extra steps. In addition to calling collectstatic to sync the static files to the remote storage, I call collectstatic with different django config file that uses local storage. After I have collected the files locally, I can call 'compress', having configured it to upload the result files to remote storage, but look in local storage for source files.