In my application, there is a field credit_debit that has two string values: 'credit' and 'debit'.
These two terms should be shown in a localized form to the user, so that when the app is using an italian locale they should be translated into 'avere' and 'dare'.
I could write my own setter/getter method for the credit_debit field and handle this issue inside it, but maybe I could leverage the I18n architecture to do so in a way that is consistent with the rest of the localization. If it's possible, how can I implement this?
Can't see the problem if you're already using i18n localization.
Just use the field as a key for i18n (with a prefix if you like)
t("prefix_#{credit_debit}")
and just define the strings for both your locales.
So in your en locale:
prefix_credit: credit
prefix_debit: debit
And in your it locale:
prefix_credit: avere
prefix_debit: dare
Related
I have an application that I'm currently localizing to Arabic but Im facing a small problem.
In the English version of the website, I display some sizes as follows 10x15 15x18 etc, and they are stored in the database as such.
In my Arabic version I want to display instead 10*15 15*18 etc.
Currently, I have a string replace function in one of the models as follows:
if I18n.locale == :ar
size.sub! 'x', '*'
end
but I'm sure that I shouldn't have code like that in a model. How can I do this using the usual I18n ways?
x in database is internal for your storage means, so strictly speaking for english you also should have size.sub! 'x', 'x' (which does nothing, because symbol is the same, but it changes it's meaning).
You're correct that symbol belongs to locale. Locales support variables in translations:
en:
some_size: "%{width}x%{height}"
ar:
some_size: "%{width}*%{height}"
I18n.t('some_size', width: size.split('x').first, height: size.split('x').second)
(to make the last expression more tidy - you can have width/height or size_hash and use splats)
I want to make a helper function which can take an English string as input and translate it to the desired language chosen by the user.
As all the locale files would be having key in common so I am looking for a way to find key using the string value. I am using default.yml files for storing translations.
After finding the key, I can use <%= t() %> for translating key to other languages.
I don't know how your yaml file looks like and it probably depends on what kind of I18n backend you use. If it's just key-value pairs for every language then something like this could work
I18n.backend.translations[:en].key "English string"
There is also the simple way. Just load the yaml file with the translations.
YAML.load_file("path_to_translations.yml").key "English string"
i want to implement the following behaviour:
if the users browser-language is e.g. EN, he should be redirected to a the url http://foo.bar/hello, if the browser-language is DE then to http://foo.bar/hallo.
so how do i need to set my routes to redirect the user to the right language (e.g. when an english user requests the DE route and vice versa) and how can i set a hidden locale parameter, so i can load the right view in the controller?
i want to use the same controller for both languages (one method per page), but localized views (foo.en.html.erb etc.)
thanks in advance!
I don't think that what you want to try to get is a good idea, and I will explain that here. I don't understand why you would choose a different approach from the ones that are provided by Rails out of the box, and explained in details in the "Internationalization Guide, Sections 2.3 and further".
Here are the arguments:
Rails provides at least 3 different ways to change the locale:
Getting it from parameters: http://my.example.com/books?locale=de
Getting it from the sub-domain: http://de.example.com/books
Client supplied application, like the accept-header
All have the advantage that the controller and action will be the same, which is what you normally want to have.
There are helper methods if you want to change your behavior depending on the locate: locale, ...
However, you may localize views as a whole if you want to do: see localized views. This will perhaps lead to a duplication in view code.
Or you use the translation and localization API as in I18n.t 'store.title' or I18n.l Time.now.
A hidden locale parameter has the disadvantage that it is not obvious (for the user) which locale is used.
If you need to translate your routes in addition to set the locale, you may have a look to the translate_routes gem.
The README explains how you can set the locale from your translation hello/hallo.
What's the best way to handle the following problem with rails 3.0.3?
I have a Model(id, name) Nationality, in which I store different nationalities
ie: French, German, Belgian
My application should be available in multiples languages, so the select input which contains the nationalities should show French, German, Belgian if the locale is set to english, and should show Francais, Allemand, Belge if the locale is set to french.
Where to store the translation and how to use them in my code?
Thanks for your help.
If you create the following structure in your en.yml:
#en.yml
en:
label_french: French
label_german: German
Then you can call the following from your views:
<%= t("label_#{#nationality.name}") %>
Have a look at the puret gem which hooks into your existing schema without changing it.
https://github.com/jo/puret#readme
All is explain on i18n rails guides : http://guides.rubyonrails.org/i18n.html
I've noticed that in my new Rails 3.0 application all German i18n strings are converted to lowercase (except for the first letter).
When having a string like this:
de:
email: "E-Mail"
the output is always like "E-mail". Same story with all the other strings - uppercase letters within a sentence are auto-converted to lowercase.
Is this default behaviour that I have to disable, or is there any other problem? I have successfully set the locale correctly, as these strings to actually work.
Thanks for your help
Arne
There should be no modifications to the content you specify as part of the internationalization process. It sounds like something is calling humanize on the string before it is output. Some of the standard Rails form helper methods do this I believe. If you just output the translation using t('email') you should see 'E-Mail' correctly.
Update:
From your comments it seems like it is a label that is causing the problem. If you explicitly specify the text for the label rather than relying on the default behaviour you will get the translation exactly as you specify. So,
<%= f.label(:email, t('email')) %>
should generate the correct label from the translations.
However, it isn't ideal. I think you may also run into problems with the generated validation error messages.
Got the same issue. solved it by adding the _html suffix to the I18n translation key. it seems that using this suffix suppresses the humanize usage.