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.
Related
I use Boost.Locale with ICU backend (internally using GNU gettext) to do the translations. This translation uses dictionaries stored on disk. Search paths are provided through boost's generator class like so:
boost::locale:generator gen;
gen.add_messages_path("path");
By inspecting the boost's source code, this internally later passes the paths to localzation backend through localization_backend::set_option. In case of ICU localization backend implementation that I use, this finally makes the paths to be set in gnu_gettext::messages_info (paths field).
Now as for my question - my requirement is to make sure that the user will not change the texts e.g. by modifying the .mo dictionary file on disk. The reason I use Boost.Locale is its codepage translations support, multiple languages support etc. and I want to keep that, but I don't want the ability for the user to freely define the texts later used in the application. My initial thought was to use the dictionaries "in memory" in some way, e.g. by storing .mo file contents inside executable and pass already read data into the localization_backend somehow. However, after checking how it works internally (described above) it seems that the only supported option is to have the dictionaries read in "real time" as I do the translations, which may include any changes to those files done by the user. It's either that or maybe I'm missing something?
What are my options?
You can use the callback field on gnu_gettext::messages_info to provide a function that will be called instead of loading messages files from disk. From Custom Filesystem Support:
namespace blg = boost::locale::gnu_gettext;
blg::messages_info info;
info.language = "he";
info.country = "IL";
info.encoding="UTF-8";
info.paths.push_back(""); // You need some even empty path
info.domains.push_back(blg::messages_info::domain("my_app"));
info.callback = some_file_loader; // Provide a callback
The callback signature is std::vector<char>(std::string const &file_name, std::string const &encoding). There's an example in the tests; this actually loads from disk, but you can adapt it to return hard-coded data instead.
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
I have a site that has many URL rewrites and a good portion of them contain old links that are prefixed with a country code (e.g. /fr, /de, etc). Rewrites without the prefixes work just fine but those with trigger Sitecore's embedded language URL parser which bypasses the rewrite module entirely.
Example
/fr/old-link tries to parse 'fr' as a language and fails as 'fr-FR' is the name of the French language.
Solution I need to disable Sitecore's ability to detect a language prefix in the URL so the URL rewrite module can proceed unhindered.
I can't find where it is in the pipeline that this occurs. I've gone through numerous with Reflector and come up short. I need help please.
Another pipeline to look at is the preprocessRequest pipeline. It has a StripLanguage processor that detects if the first part of the URL is a language and acts on it.
More info on how to get Sitecore to ignore the language part of the url can be found in this post http://sitecoreblog.patelyogesh.in/2013/11/sitecore-item-with-language-name.html
You will need to create a new LanguageResolver to replace the standard Sitecore one (Sitecore.Pipelines.HttpRequest.LanguageResolver). This is referenced in the <httpRequestBegin> pipeline section in web.config. Here you can handle requests beginning with fr as opposed to fr-FR etc. In the past I have done a similar thing for when we wanted to use non-ISO language codes.
EDIT
The LanguageResolver resolves language based on query string first, but will also resolve based on file path (i.e. having fr-FR in the start of your path). I think you would need to inherit from the Sitecore LanguageResolver and override the GetLanguageFromRequest method changing the else statement to use something different to Context.Data.FilePathLanguage - possibly just using regex/string manipulation to get the first folder from the URL then use that to set the context language. This should prevent the failure to resolve language which I understand is killing your URL rewrite module.
i get an unicode error when trying url like www.mysite.com/blog/category/πρακτικα/ or www.mysite.com/blog/πρακτικα/
but i dont get the error when trying www.mysite.com/blog/tag/πρακτικα/
UnicodeEncodeError at /blog/category/πρακτικα/ 'latin-1' codec can't encode characters in >position 58-65: ordinal not in range(256)
Exception Location: /home/vagrant/sullogos-venv/local/lib/python2.7/site-packages/django/template/loaders/filesystem.py in load_template_source, line 37
seems it haves different behavior at categories and at tags
The difference is that categories can have a custom template and tags can't. So in the category case, a template name is searched for using the category slug - the error you're getting is due to an incorrectly configured locale which doesn't support utf8.
This is not a problem with Mezzanine or Django, but with the environment used to deploy them. See this issue and this documentation for more details. It's not enough for Python to support a specific locale, but it's also necessary for the webserver to be able to handle Unicode files correctly.
How to fix it will depend on the webserver used. If you're using Apache, for instance, you need to set LANG and LC_ALL to Unicode-compatible values (on *NIX systems at least you should find them at /etc/apache2/envvars). An example would be:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Feel free to replace the language/country codes with another one more suitable for your needs (I used pt_BR instead of en_US and things worked fine for me). From the error message you're seeing, these settings in your system are probably using ISO-Latin (ISO-8859-1) instead of UTF-8 (which I assume can't handle cyrillic).
If you're using a different webserver, check its documentation on localization/internationalization to see what needs to be changed. The important thing is to offer support to Unicode file names, as I understood.
I have installed the django-rosetta for translation, made .po and .mo files through django command
django-admin.py makemessages -l ar
and translate all words through django-rosetta,
now when i change my language to Arabic from English, it show some words in Arabic and some in English, although i have translated all these words in Arabic,
Have you restarted you web server?
This means your project's labels will be translated right away, unfortunately you'll still have to restart the webserver for the changes to take effect. (NEW: if your webserver supports it, you can force auto-reloading of the translated catalog whenever a change was saved. See the note regarding the ROSETTA_WSGI_AUTO_RELOAD variable in conf/settings.py.
-- http://code.google.com/p/django-rosetta/
What kind of server are you running?
I had the same problem with Apache2 and FastCGI. I had to restart the FastCGI Process to see the modifications.
Have you added the local path properly to your settings?
PROJECT_PATH = os.path.split(os.path.abspath(os.path.dirname(__file__)))[0]
LOCALE_PATHS = (
os.path.join(PROJECT_PATH, "locale"),
)
Do you have translations marked as fuzzy? (In Rosetta you can filter to display only fuzzy translations.) If some strings are fuzzy, make sure they are properly translated, uncheck the fuzzy flag and save the translations.
Another reason for translations not showing up could be that some python formatting strings (e.g. 'My %s apple') are not properly reproduced in the translated string. If formatting codes are unbalanced Rosetta should warn you, and the actual translation doesn't get written to the file.