currently I'm working over a task, which require every Django user to have different locale file and translation of course e.g. different translation for the same app.
I'm tried to do some changes on my own scenario and the next lines are finished and works fine but I also met some troubles
whole app is translated on english and german
when I create new user, I copy default translation file .po to new directory related to this user. For this case I made container app which hold all custom translation and directory with schema like this 'apps/trans/locale/user1/', 'apps/trans/locale/user2/' and so on.
these paths are added into settings.LOCALE_PATHS when app is started.
I have implemented rosetta into my Django admin and display correct .po file for all of them (custom .po)
The Django tempalatetags i18n.py was copied into my teplatetags directory and was extended for my purpose
I also want to do some custom modification into django.core.translation module and I also copy this file into my project, but now I do not know how to load this module correctly to override the default Django functionality, because I want to replace the default translation with custom here
for now I use _ _ import _ _ and then I just replace sys.modules['django.utils.translation'] with my module. is this a correct way?
So anyone with idea?
Thanks
Related
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.
I am trying to separate my admin code from my public code, I want to create 2 different directories in my app folder and resources folder, 1 directory named backend which contains all my admin code and another named frontend which contains public related code.
Each directory will have their own separate controllers.
Basically something like this:
-App
--frontend
--backend
-resources
--views
---frontend
---backend.
If there is a better way to do this i would also like to know.
By default you composer.json is autoload all in app. So you can make the structure which you described above.
Frontend and backend separating usually used for Controllers, in this case you need to make a correct namespace.
With views you would'n have any porblems. Just make a correct path when you calling your views.
For example:
view(frontend/index); // you can use dot instead of /
I am trying to make sprokets compile a single standalone js asset, so it will uglify and minify it and be part of the entire rails projects.
I need that this js to have a non-digest name, so it's will not change (i.e. embedded in other websites, etc)
I can't seem to force rails (4) /sprockets to do my bidding.
What I tried:
Adding the asset (script.js) in a misc folder unders assets/javascripts and not load it in the sprockets javascript manifest. While this keeps it in the project, it doesn't get uglified and minified, and doesn't get automatically loaded via asset-sync.
Tried adding another manifest called scripts-manifest.js to //= require script.js asset, to add its path in the precompile path in application.rb, but the problem is that rails 4 adds digest to all assets no matter what (doesn't work like that in rails 3)
Tried using https://github.com/alexspeller/non-stupid-digest-assets to add a non digest version of the asset. I may have done it incorrectly, as it doesn't work or do anything..
I add the initializer NonStupidDigestAssets.whitelist = ["script.js"] and tried putting it in app/assets/javascripts/misc and in public/ but it still won't work/
I have read that this gem should help in most cases, and I am sure I am doing something wrong with either path definition or no including it somewhere
One way to do this is to add an initializer that generates the compiled versions directly.
Add your js file to a subfolder in /app/assets/javascripts. Don't include this in application.js so it isn't added to the compiled assets.
Create an initializer in /config/initializers that uses uglify directly
output_file = "#{Rails.root}/public/public_script.js"
input_file = "#{Rails.root}/app/assets/javascripts/non_digest/public_script.js"
uglified = Uglifier.compile(File.read(input_file))
File.open(output_file, 'w') {|f| f.write(uglified) }
Include the public js file (in this example: /public/public_script.js) in your application layout
This way you have direct access to make custom changes to how uglify handles your js and the location of the file never changes for your external services accessing them.
I did all this locally and tested that it worked using the beta version of Rails 4.2
Just wanted to add my own solution based off Ken's answer.
I created non_digest.rb in config/initializers:
Dir["#{Rails.root}/app/assets/javascripts/non_digest/*"].each do |asset|
asset_name = File.basename(asset)
asset_output = "#{Rails.root}/public/external/#{asset_name}"
asset_uglified = Uglifier.compile(File.read(asset))
File.open(asset_output, 'w') {|a| a.write(asset_uglified) }
end
Don't forget to stub the file in javascripts/application.js. as we probably don't want it compiled with the rest of our JS and we can continue to use //= require_tree .:
//= stub non_digest/external_bookmarklet
the way you would do this with rails 4 is the following:
add it to the precompile list config.assets.precompile += %w(your_file_name.js)
make sure it's not referenced in application.js (directly or via require_tree)
symlink the digested file on deployment
read the manifest.yml to get the actual filename
ln -s digested-filename.js actual-filename.js
since rails 4, generation of non-digested assets has been removed (for good reasons) and this is a simple and straight forward way to implement the desired behavior.
I've got a Django project spinning up where it would be great to have the UI in lots of color schemes based on the users' school colors. I have this fantasy of having a base variables.less file along with a bunch of other .less files that compile into style.css.
But once a user sets their school colors it generates a blue.variables.less file (if they've selected the blue preset) or school123.variables.less file (if they got all fancy and used the color picker to make their own color scheme) and then compiles everything to blue.style.css or school123.style.css and then that's the .css file we load when we serve the page.
I can imagine lots of ways for this to fall down. Like how do I reprocess all those files when I push an update to forms.less or layout.less.
Is there a better way to do this? I Googled my fingers raw but haven't found anyone attempting this madness.
There are quite a few ways to accomplish your goal of being able to have user specific color schemes, but they each have their advantages / disadvantages.
I'm assuming you are using some framework like Bootstrap with the files that you name.
Option 1: Inline CSS for color-specific styles (Preferred)
This is my preferred option due to performance and simplicity. You can store each of the customized colors for each user, or even creating a model so you can reuse colors that represent a specific school. It's stored in the database and can scale to an very large number of color schemes without generating a lot of very similar files.
Create a snippet in your template code that has any style that uses the color variable.
base.html
{% include "color-snippet.css" with main-color="{{ user's main color }}" alt-color="{{ user's alt color }}" %}
color-snippet.css (note this file will be in your templates directory as it's being handled by your template engine
<style>
.some-style {
color: {{ main-color }} !important;
}
</style>
So the big downside to this is you'll need to customize Bootstrap beyond the variables.less. You'll need to grep through the less files to find all the classes that would be generated, and copy the style to your snippet in css and not less. It'll take some investment up front and work when you want to upgrade to a newer Bootstrap, but it'll allow you to separate the color part of the styles to be derived dynamically at runtime.
I prefer this approach since you don't have to deal with compilation of less outside your collectstatic step.
Option 2: Client side compilation of LESS
You can have Django serve a file that is dynamically created and returns the variables you want. Then you can have less.js compile it on the client.
This would involve adding to your base template a url path that is handled by Django that isn't part of your static path (e.g. /style/variables), creating a handler in views and then returning text content that would be your less file variables.
Option 3: Server side compilation of LESS
I use Django Pipeline to do my server side compilation of less to css. It takes some setup to get working with your Django application. In development mode, Django Pipeline will compile on every request the associated less files into CSS files. In production mode, it'll point to the appropriate file path to the compiled file. It hooks into collectstatic so your less gets compiled when you collectstatic.
The biggest problem with this approach is that the mapping for your static files (what less + css files compile to css) is defined in your settings file. This requires a server restart when you update this. You could base your own server side less compilation off how Django Pipeline works but have logic for the mapping instead of defining it in something that requires a server restart.
It's a lot of work and the less compilation of Bootstrap is non-trivial to have to do on every request.
If you created your own mapping that doesn't require you to restart your Django server process, you could always just run collectstatic to create the new css files. This would avoid compilation at every request.
While this last approach is closest to what you mentioned, it seems a lot more work and error prone than just separating the color-specific styles and using django templating to customize it.
The last approach as well works well if your number of schemes is rather low since you can just create all the mappings ahead of time and not let people generate their own at runtime. They can suggest them and you can just update them at some regular cadence.
Django's default LANGUAGES settings contains zh-cn and zh-tw. However, I would like to use zh instead of zh-tw. I've set up my LANGUAGES setting appropriately and compiled the gettext messages but Django will only load the zh-cn translation.
Frustratingly, gettext will load the zh translation fine if I delete the zh_CN directory!
Is there any way to get zh to load the right translation?
My assumption on this is because django itself is only translated into zh-cn and zh-tw. Django translation will only allow you to translate into a language Django itself is translated for.
You should try to translate Django into zh (or copy zh-tw into zh).
Maybe the "Using Gettextize software" from GNU C help.
http://www.gnu.org/software/libc/manual/html_node/Using-gettextized-software.html
Quote:
The file /usr/share/locale/locale.alias (replace /usr with whatever
prefix you used for configuring the C library) contains a mapping of
alternative names to more regular names. The system manager is free to
add new entries to fill her/his own needs. The selected locale from
the environment is compared with the entries in the first column of
this file ignoring the case. If they match the value of the second
column is used instead for the further handling.
Note that the in some system (e.g. Fedora 21), /usr/system/locale/locale.alias is obsoleted and just for backward compatibility.