I'm creating a multi-page document in two different languages (English and French) with possibly other languages to be added. The url of a given document will take the form of prefix/en/name.html or prefix/fr/name.html i.e. only the "en" or "fr" part will be different. Is is possible to include some code in the main template (layout.html ... or elsewhere?) that would take the url of the current (English) document, replace "/en/" by "/fr/" and insert it as a link to the "French" version? Something like
automatically retrieve:
prefix/en/this_document.html
transform into:
French
I essentially found the answer I needed in this post: https://groups.google.com/forum/#!topic/sphinx-users/Xmbs5AbnVKY
Basically, what I do is insert the following:
{{"English version"}}
where needed.
Related
I am doing a web application, which uses Elasticsearch for search and was designed to support multiple languages. In the mapping, I have a few fields that look like this:
"myfield": {"properties": {"en": {}, "zh_TW": {}, "ar": {}, ....}}
However, when it is launched, it will support only one language (English). The support for other languages will be added later, and we plan to add support for many languages in the future.
Should I add all possible language codes (such as "en", "zh_TW", ...) in the mapping now (obviously this is a very long list)? Or should I add a language code only when its language is introduced into the system?
For the second approach, what is the extra work or operational impact? Do I have re-index of all documents? What other things I have to know now?
Thanks for any input!
Having to reindex the documents is not a concern because you'll have to update the documents anyway to add the content in the new language, won't you?
So, put the mapping for each newly supported language just before putting the first text in that language.
I suggest that you duplicate your fields for each supported language, like:
"myfield_en" : ...,
"myfield_zh_TW" : ...,
"myfield_ar" : ...
beacuse it's easier to put the mappings.
When you start supporting , say, German, put a mapping with German Analyzer for a new field "myfield_de". After that, every time you insert or update a document with German translation the German field will be analyzed.
If you have documents without German translation, they're not going to need a reindex.
Conclusion: pointless to put a mapping for a field when you don't have any text to write there yet.
I'm developing a Firefox extension that involves dictionaries in various languages and dialects. I want to display a dialog to the user to select spell checking dictionaries for the available languages.
It will be tedious for the user to select from values like en-US, ar-EG, en-GB, etc., so, I want to display the localized language names like what Firefox does in this screenshot
This is the dictionary selection menu on my Arabic Firefox displaying the names of the two languages en-US and ar.
How to do such thing?
Here is what I did to find and use these strings:
1- I downloaded the whole Firefox source code and extracted it.
2- I searched the source files for the name "New Zealand". This unique country name should exist only in the file I'm looking for. Rather than using general terms like English, United States, Arabic, etc.
3- The search led me to two interesting files: regionNames.properties and languageNames.properties. The first has the names of all countries and the other has the names of all languages. Firefox should be using the two sets of strings to display dictionary names.
4- I found that the two files can be fetched from the URLs chrome://global/locale/languageNames.properties and chrome://global/locale/regionNames.properties, so, I used the string bundle service and the string bundle objects to load and use the resources.
Here's a code sample:
On the top of my main.js file:
const {Cc, Ci, Cu} = require("chrome"),
stringBundles = Cc["#mozilla.org/intl/stringbundle;1"].getService(Ci.nsIStringBundleService);
Then I have this piece of code in another method:
let languagesNamesBundle = stringBundles.createBundle("chrome://global/locale/languageNames.properties"),
countriesNames = stringBundles.createBundle("chrome://global/locale/regionNames.properties");
console.log(languagesNamesBundle.GetStringFromName("ar")); // العربية Arabic
console.log(languagesNamesBundle.GetStringFromName("af")); // الأفريكانية Afrikaans
console.log(countriesNames.GetStringFromName("fj")); // فيجي Fiji
console.log(countriesNames.GetStringFromName("cr")); // كوستا ريكا Costa Rica
And this is what I wanted. Now I can compose dictionary names from languages and countries names.
I'll update the answer to add the path of the project repository after I publish the final result.
This is very easily doable. I have some very basic templates for localization here:
https://github.com/Noitidart/l10n/tree/xhtml-xul
https://github.com/Noitidart/l10n/tree/properties
properties files are for within privelaged js file localiztion. and .dtd is used for xul/xhtml/and inline javascript.
I have Magento 1.8.1.0. Recently I've installed Russian pack, the result wasn't appropriate enough, cause some phrases on frontend remained in English
I know there's handy way to translate Magento using cvs-files.
The question is where I can find proper cvs-file? Does installed theme concerns translation some how? I know I'm asking newbie questions, I've read several posts, but I haven't made up my mind how to translate Magento.
Many thanks in advance.
Hope you are doing well,
As i have gone through your question that you want to translate your websites front end in Russian if user has selected the language Russian.
For this you are required to work out the translate.csv files which will be available in your theme Package.
Example : app/design/frontend/default/SecuareWeb/locale/de_DE
In the locale folder you will find the folder for Russian language open that folder and you will find the file where you are required to add the required translation text in it.
How to add translation text in translate.csv file is given below.
Example:
"This is the demo of translation in Russian","Это демо-трансляции на русском языке"
And one thing i would like add is that make sure your front end .phtml files must contain the text in $this->__("Example");. If you have added all the text like this then only then it will allow you for translation other wise it will not translate a text.
Hope this might be use full to you !!!
Waiting for your valuable comments in regards to your Question !!!
There are different ways to achieve translation in Magento so you can find multiple directory containing static csv files and also a database table.
All the modes have same structure: key/value. For example: "String to translate","String translated".
Inline Translation (database table: core_translate):
following best practices in Magento, you should use inline-translation aka database saved translation in rare cases. It is harder to mantain and can be buggy. It has first precedence, so any translation you do via inline translation will override the other 'modes'.
Theme level Translation (file in app/design/frontend/your_package/your_theme/ru_RU/translate.csv):
you can place any string to be translated in the translate.csv. It has second precedence.
Locale translation (file in app/locale/ru_RU/Module_Name.csv):
the suggested way to do translation as it will keep translation separated by each module and is easier to maintain. For example: Mage_Catalog.csv etc.
Each module in Magento can specify its csv file containing translation and sometimes the same string has different modules trying to translate, so if your translation does not work check between multiple file by a quick editor search. It will be overridden by the two above modes.
Note:
Magento will load all the csv files and build up a giant tree and caches it. So before scratching your head because the string is not translated as you wished in the frontend:
1. clean the cache.
2. check for any same key string which comes after your translated string. For example: in the same csv Line 100 will override Line 1 if the key string are the same.
3. check for any same key string in the mode which has higher precedence. For example: inline translation will override any csv based translated string.
It may be easier for you to go to the admin backend System -> Configuration -> Developer and switch "Translate Inline" "Enabled for Frontend" to "Yes".
Then, refresh the frontend and you can change the translation directly at your web browser.
The translation is saved in the database table core_translate just for the case you want to do it in a test environment and copy the translation later on to the production.
Take care that without client restrictions (System -> Configuration -> Developer) everyone will see the translation options.
btw. You may need to clear the cache and refresh the webpage in order to see your changes.
Does Expression Engine have a built-in solution for i18n (internationalization)?
I have to build a multi-language site, and would like to know the best approaches in EE for doing so.
There are many ways you can create a multilingual or country-specific site in ExpressionEngine to deliver content specific to each language/country.
The two most popular solutions are summarized from the following ExpressionEngine Wiki articles:
MultiLingual Websites in ExpressionEngine
The basic idea is to present your content in different languages using a combination of URL Segments, custom fields and a bit of PHP.
Advantages
Single entry manages multiple languages
Simple URL structure
As an example, say you have a 3-language site: English (en), Spanish (es) and German (de).
For every piece of content in your site, you'd create a custom field with the language identifier as a postfix (or prefix, whatever you prefer) to the fields.
Your custom field names might look like this:
custom_field_en
custom_field_es
custom_field_de
To switch between languages, simply add a corresponding URL segment (/en, /es or /de) that matches the language:
example.com/template_group/template/en
example.com/template_group/template/es
example.com/template_group/template/de
The main advantage of this approach is that it keeps all versions of your content inside a single entry, making updates and edits easy and consistent.
MultiLingual Websites in ExpressionEngine, Alternative
The alternative approach idea is to create sub-directories for each country, and use ExpressionEngine's path.php Global Variables to hold the country code and/or language as a variable.
Advantages
No PHP needed
No need to keep track of which segment holds the language variable
Elegant URL structure
Using the same 3-languages as an example from the first method, you would create a new directory in the root of your EE install and name it after the country code of the language you want to add:
Your folder structure might look like this:
+ /de
+ /en
+ /es
index.php
+ /images
+ /system
+ /themes
To allow this method work, place a copy of the main index.php inside each of the language directories. You would then modify each file by assigning variables corresponding to each language's directory:
$assign_to_config['site_index'] = 'http://www.example.com/en/';
$assign_to_config['global_vars'] = array(
"country_code" => "en",
"language" => "english"
);
The URLs built will use whatever language/country designation you choose:
example.com/es-MX/template_group/template/
example.com/MX/template_group/template/
The main advantage of the alternative approach is using Global Variables, leveraging the fact they are are parsed very early, and can be used almost anywhere in templates.
See: ExpressionEngine's Parse Order (PDF, 33 KB)
Other Solutions
Embracing the philosophy of ExpressionEngine, the flexibility you're given as a designer/developer allows you to tailor a custom solution that suits your unique needs.
If either of these approaches don't quite meet your needs, you can eaily craft your own method or take a hybrid approach.
With this in mind, a good starting point would be to look into the Multilingual Add-Ons at Devot-ee that may aide in your development.
We do have a website which should be translate into different languages. Some of the wording is in message properties files ready for translation. I want now add the rest of the text into these files.
What is a good way to name the text blocks?
<view>.<type>.<name>
We mostly have webpages and some of the elements/modules are repeating on some sites.
As far as I know, no "standard" exists. Therefore it is pretty hard to tell what is proper and what is improper way of naming resource keys. However, based on my experience, I could recommend this way:
property file name: <module>.properties
resource keys: <view or dialog>[.<sub-context>].<control-type>.<name>
We may discuss if it is proper way to put every strings from one module into one property files - probably it could be right if updates doesn't happen often and there are not so many messages. Otherwise you might think about one file per view.
As for key naming strategy: it is important for the Translator (sounds like film with honorable governor Arnold S. isn't it?) to have a Context. Translation may actually depend on it, i.e. in Polish you would translate a message in a different way if it is page/dialog/whatever title and in totally different way if it is text on a button.
One example of such resource key could be:
preferences.password_area.label.username=User name
It gives enough hints to the Translator about what it actually is, which could result in correct translation...
We have come up with the following key naming convention (Java, btw) using dot notation and camel case:
Label Keys (form labels, page/form/app titles, etc...i.e., not full sentences; used in multiple UI locations):
If the label represents a Java field (i.e., a form field) and matches the form label: label.nameOfField
Else: label.sameAsValue
Examples:
label.firstName = First Name
label.lastName = Last Name
label.applicationTitle = Application Title
label.editADocument = Edit a Document
Content Keys:
projectName.uiPath.messageOrContentType.n.*
Where:
projectName is the short name of the project (or a derived name from the Java package)
uiPath is the UI navigation path to the content key
messageOrContentType (e.g., added, deleted, updated, info, warning, error, title, content, etc.) should be added based on the type of content. Example messages: (1) The page has been updated. (2) There was an error processing your request.
n.* handles the following cases: When there are multiple content areas on a single page (e.g., when the content is separated by, an image, etc), when content is in multiple paragraphs or when content is in an (un)ordered list - a numeric identifier should be appended. Example: ...content.1, ...content.2
When there are multiple content areas on a page and one or more need to be further broken up (based on the HTML example above), a secondary numeric identifier may be appended to the key. Example: ...content.1.1, ...content.1.2
Examples:
training.mySetup.myInfo.content.1 = This is the first sentence of content 1. This is the second sentence of content 1. This content will be surrounded by paragraph tags.
training.mySetup.myInfo.content.2 = This is the first sentence of content 2. This is the second sentence of content 2. This content will also be surrounded by paragraph tags.
training.mySetup.myInfo.title = My Information
training.mySetup.myInfo.updated = Your personal information has been updated.
Advantages / Disadvantages:
+ Label keys can easily be reused; location is irrelevant.
+ For content keys that are not reused, locating the page on the UI will be simple and logical.
- It may not be clear to translators where label keys reside on the UI. This may be a non-issue for translators who do not navigate the pages, but may still be an issue for developers.
- If content keys must be used in more than one location on the UI (which is highly likely), the key name choice will not make sense in the other location(s). In our case, management is not concerned with a duplication of values for content areas, so we will be using different keys (to demonstrate the location on the UI) in this case.
Feedback on this convention - especially feedback that will improve it - would be much appreciated since we are currently revamping our resource bundles! :)
I'd propose the below convention
functionalcontext.subcontext.key
logicalcontext.subcontext.key
This way you can logically group all the common messages in a super context (id in the below example). There are few things that aren't specific to any functional context (like lastName etc) which you can group into logical-context.
order.id=Order Id
order.submission.submit=Submit Order
name.last=Last Name
the method that I have personally used and that I've liked more so far is using sentence to localisee as the key. For example: (pls replace T with the right syntax dependably on the language)
for example:
print(T("Hello world"))
in this case T will search for a key "Hello world". If it is not found then the key is returned, otherwise the value of the key.
In this way, you do not need to edit the message (in your default language) at least that you need to use parameters.... It saved me a LOT of dev time