On my rails app there is a select box with values of, fuel_types, such as, Oil, Gas, Petroleum, Diesel. The default language is en so this is fine.
When user changes website to french these data should be shown as french and when user submits the form, the data should be in fr however, I can not do it by using
fr:
fuel_types:
oil: ""
gas: ""
petroleum: ""
Because then database data will be mixed with fr and en language. I then have to show these data in the show page, if fr or en.
Is this possible with globalize3 gem ?
I see that static content in database can be translated with globalize3 but while user filling the form it is either fr or en according to locale variable then the database will be populated with en and fr values, it will make almost impossible to search data and process.
btw: I have a model called fuel_types with name id columns, where I keep oil, gas, petroleum values to show in select tag. Then I save them to car model.
EDIT
In this way you are right!. But what if I have;
...
<%= f.collection_select(:fuel_type, Fuel.all, :name, :name, {}, class: "Select-control u-sizeFull") %>
...
I have model called Fuel and this fuel (belongs to car model) should be seen as the locale variable. Then should be written in one language to database?
So for edited question: third and fourth argument can be anything that responds to call so instead of using name in fourth argument use proc {|fuel| translate(fuel.name)} or any other translation method you have, just call it in proc.
Related
New to rails and I'm trying to write a large form (30+ inputs almost all numbers)
Mostly radio buttons and maybe some sort of increment buttons. Some radio buttons will give a range 5-10min but when submitted these attributes need to submit a normalized standard number 8 for example so that calculations can be performed. How can I have radio buttons or drop downs that show the user one thing but submits something else behind the scenes to postgresql?
You can use a select with an options_for_select. This will allow you to display something that is different from what is sent in the params to the controller
It would be something along the line of:
<%= f.select :some_attribute, options_for_attribute, {}, prompt: 'Select One' %>
and then off in your application helper or somewhere:
def options_for_attribute
[
['1','8'],
['2','9']
]
end
See:
https://apidock.com/rails/ActionView/Helpers/FormOptionsHelper/options_for_select
Given the phrase:
"You've successfully donated €10 to Doctors of the World"
I wanted to dynamically generate this text for different amounts and charity names, which i did using
_("You've donated %{amount} to %{charity_name}")
Where charity_name comes from a list of possible charities and each charity is a hash with data about the charity.
I'm not a french speaker and only learnt basic french in school but the problem with doing this (which is probably immediately obvious to any speaker of a language with gendered articles) is that the "to" part of the translation can take various forms a la, au, a'l or aux depending on the noun.
eg "Vous souhaitez donner 10€ aux Médecins du Monde"
What is the best way to handle this using gettext, given that this will need to be scaled to other languages? There are only a few cases where this will need to be done because most cases of dynamic text (99%+ can be handled fine with parameters.
I've thought of 3 ways to do this:
1) Have highly dynamical text such as this generated from a function, one per message per language as necessary. The function accepts an amount and charity name as a parameter and returns the translated text.
2) Manually add a translation for "to " for each charity and use that in place of %{charity_name} and then get the translation from the po file.
3) Add an entry in each charity hash specifying the form of the "to " eg the hash for les Médecins du Monde would also store aux Médecins du Monde.
Are any of these methods viable or is there a better alternative I'm not thinking off?
May be not the best approach but I've used this for several times.
Consider a table with below fields:
id, name_en, name_ru, created_at, updated_at
I assume that you use I18n to get language parameter.
controller
def index
#lang = params[:locale] || I18n.locale
#examples = Example.all
end
view
<% #examples.each do |ex| %>
<li>
<%= ex.send("name_#{#lang}") %>
</li>
<% end %>
Above code will present name_ru (name in russian) or name_en (in english) based of I18n.locale
I have a User class, which has an Address object with a phone field. Due to the nature of this project, we are saving phones in all sorts of formats (dashes, spaces, no spaces etc.). On my AA users.rb, I want to specify a filter that will standardize the phone data (get rid of dashes and spaces) of the saved data, and then perform the search against the admin input.
So the admin could search something like 1234567 and it would return 123-4567.
I'm hoping that something exists like...
ActiveAdmin.register User do
...
filter :email
filter :name
filter :address_phone, custom: { Address.all.map{|x| x.phone.gsub("-","") }
...
I appreciate it if anyone knows an easy way to accomplish this.
Below example is taken from this documentation page:
https://github.com/activescaffold/active_scaffold/wiki/Chaining-Form-Fields
[Example start]
You can set an array of columns to update multiple columns when a column changes, and chain column updates:
class UsersController < ApplicationController
active_scaffold do |config|
config.columns[:author].form_ui = :select
config.columns[:author].update_columns = [:book, :editorial]
config.columns[:book].form_ui = :select
config.columns[:book].update_columns = :format
end
end
In this example, fields for book, editorial and format are updated when author changes, and when book changes only format is updated. A form override which use the new author or book must be defined for editorial and format columns, in other case those fields won’t change when they will be rendered again.
[Example end]
In the example it states "a form override which use the new author or book must be defined".
Question is how to define those form overrides ??
I have read the documentation on https://github.com/activescaffold/active_scaffold/wiki/Form-Overrides, and tried different form overrides, but with no luck so far, i.e. the columns are not being rendered again.
If you can help me with the code for those form overrides needed in the given example, then I should be able to port that to my code.
Here is the solution to my problem:
I followed the example on "https://github.com/activescaffold/active_scaffold/wiki/Chaining-Form-Fields", but when it did not work for my chained columns (when updating the first column all chained columns updates correctly, but when updating the second column then its chained columns renders to blank lists), then I focused (blindly?) on the details explained just below the example as I thought this was the first step to solve my problem: "A form override which use the new author or book must be defined for editorial and format columns, in other case those fields won’t change when they will be rendered again".
This was however not the case, no form override in the helper was needed to get this to work, in the helper the "options_for_association_conditions" is enough. As the example is for v2.4, maybe the form override is not needed anymore in v3.0+.
The solution is in the next paragraph on the example wiki: "Usually only the value of the changed column is sent, if you need another values to render the updated columns, enable send_form_on_update_column and all the form will be sent". My problem was, that the columns which was chained from the second column needed the value from the first column also, so setting up the second column with "send_form_on_update_column" (i.e. sending the whole form, not just its own value) solved my problem.
In the example this would be:
config.columns[:book].send_form_on_update_column = true
I am currently working on a project to internationalize one of our ruby-on-rails web applications so that it can be used in other countries (France will be the first one in this case).
A particular issue I haven't worked out yet is with the displaying of numeric fields. When displaying numbers for display purposes only, I do the following:
<%= number_to_percentage(tax.rate, :precision => 2)%>
In English, this shows 17.50, but in French it shows 17,50 (with a comma in place of the decimal point) which is as expected. The problem comes in the Edit form, when I show a text field
<%= f.text_field :rate, :size => 15 %>
When this renders a text box on the screen, the text box always shows 17.50 with a full stop rather than a comma for French. I am not sure that is correct.
When I tried doing the following:
<%= f.text_field :rate, :size => 15, :value => number_with_precision(f.object.rate, :precision => 2) %>
This did indeed show 17,50 in the text box for French, but when I click on the Update button to save the form, the Ruby validation kicks in and tells me that 17,50 is not a number (or rather it says "n'est pas un nombre"). I have to enter 17.50 to get it to save.
To be honest, I am not entirely sure on the correct thing to do here. Should all countries enter numbers with full stops in text boxes, or is there a way to get Ruby-on-Rails to display commas, and validate them appropriately?
TL;DR
This is the kind of things I hate to do over and over again (I'm serving french users, they're easily confused with dots as the decimal separator).
I exclusively use the delocalize gem now, which does the format translation automatically for you. You just have to install the gem and leave your forms as-is, everything should be taken care of for you.
I like to read, give me the long explanation
The basic conversion is quite simple, you have to convert back and forth between the following formats:
The backend one, which is usually English, used by your persistent storage (SQL database, NoSQL store, YAML, flat text file, whatever struck your fancy, ...).
The frontend one, which is whatever format your user prefers. I'm going to use French here to stick to the question*.
* also because I'm quite partial towards it ;-)
This means that you have two points where you need to do a conversion:
Outbound: when outputting your HTML, you will need to convert from English to French.
Inbound: When processing the result of the form POST, you will need to convert back from French to English.
The manual way
Let's say I have the following model, with the rate field as a decimal number with a precision of 2 (eg. 19.60):
class Tax < ActiveRecord::Base
# the attr_accessor isn't really necessary here, I just want to show that there's a database field
attr_accessor :rate
end
The outbound conversion step (English => French) can be done by overriding text_field_tag:
ActionView::Helpers::FormTagHelper.class_eval do
include ActionView::Helpers::NumberHelper
alias original_text_field_tag text_field_tag
def text_field_tag(name, value = nil, options = {})
value = options.delete(:value) if options.key?(:value)
if value.is_a?(Numeric)
value = number_with_delimiter(value) # this method uses the current locale to format our value
end
original_text_field_tag(name, value, options)
end
end
The inbound conversion step (French => English) will be handled in the model. We will override the rate attribute writer to replace every French separator with the English one:
class Tax < ActiveRecord::Base
def rate=(rate)
write_attribute(:rate, rate.gsub(I18n.t('number.format.separator'), '.')
end
end
This look nice because there's only one attribute in the example and one type of data to parse, but imagine having to do this for every number, date or time field in your model. That's not my idea of fun.
This also is a naïve* way of doing the conversions, it does not handle:
Dates
Times
Delimiters (eg. 100,000.84)
* did I already tell you I like French?
Enter delocalize
Delocalize is working on the same principle I outlined above, but does the job much more comprehensively:
It handles Date, Time, DateTime and numbers.
You don't have to do anything, just install the gem. It checks your ActiveRecord columns to determine if it's a type that needs conversion and does it automatically.
The number conversions are pretty straightforward, but the date ones are really interesting. When parsing the result of a form, it will try the date formats defined in your locale file in descending order and should be able to understand a date formatted like this: 15 janvier 2012.
Every outbound conversion will be done automatically.
It's tested.
It's active.
One caveat though: it doesn't handle client-side validations. If you're using them, you will have to figure out how to use i18n in your favourite JavaScript framework.
This is the gsub technique :
In your model :
before_validation :prepare_number
def prepare_number
self.rate.gsub(/,/, '.') if self.rate.match /,\S/
end