We have some translation strings like
“Search in %{category_name}”
or
“Delivery to our showrooms in %{list_of_locations}”
In Swedish and English, it works fine to just pass in @category.name
or @locations.to_sentence. But in Finnish, instead of “in Foo” you
might say “Foossa”, using a suffix instead of a preposition (inessive
case). And similarly, you might say “Fooan ja Baran” for “to Foo and
Bar” (illative case).
And as I understand it, these suffixes are irregular - you can’t just
do @locations.map { |x| “#{x}ssa” }.
I’m very interested to hear how others handle this. Are there i18n
conventions?
The best solutions I can think of is to have e.g. a
category.name_inessive_fi column (and not have columns for Swedish and
English, or leave them empty and fall back), and to do similarly for
the locations or to have translation keys for e.g. stockholm_illative.
Henrik
I think this is a general problem also for other languages as e.g.
Swedish
For example, “New %{attribute_name}” where attribute_name is name,
decription, time etc should in Swedish be translated as “Nytt namn”,
Ny “beskrivning” etc
As i understand it the only way to solve this problem is to have
specific translations for each case of “New #{attribute_name}” , as
otherwise you end up with writing some kind of grammar
,e.g rules for when to use Ny and Nytt.
However, when it comes to langauge , there are allways exceptions
that you are not aware of, according to my experience. There are no
simple rules!
Hans M.
St: Larsgatan 50, 58224 Linkping, Sweden
Phone: +46708371202
10 jun 2011 kl. 11.26 skrev Henrik N.:
That’s a good point. In this case, the categories and locations are
dynamic (in the DB), and are part of complex phrases with a
combinatorial explosion of different variations, so translating them
in full wouldn’t work well.
We’ve had this kind of problem with locations and categories too. It is
a hard problem, especially when you have the combinatorial explosion.
One way we’ve worked round it is by not having sentences, so something
like %{attribute_name}: New. Probably won’t help in this case but it’s
something to consider doing.
There was a gem that had an interesting approach,
GitHub - redox/genderize: Provide a gender-based distinction for I18n.translate, maybe something worth considering
too.
Chris
Thanks. That’s a decent workaround, and the plugin does have an
interesting take.