Translation: hosting an english-language foodsoft site

[wvengen]

Hi, is there a way to provide an English (or other) translation? I see config/locales/en.yml but found that providing a translation there did not translate the templates. How would this work?

[bennibu]

hey wvengen,

thanks for your interest. In fact, adding translations to the english
locale file isn't enough at this moment. First we have to replace all
strings in the templates with the appropriate rails i18n helper methods.
like

template file

t('articles.index.search')

locales/en.yml

articles:
index:
search: Search in articles..

I am currently not sure, when I am have the resources to do so. First I
have to finish the migration from the old (master branch) to the new
version (rails3 branch). At the moment I am testing the rails3 version
with some foodcoops. I guess, the migration will be finished in about 3
weeks. Maybe after that we can start with that.

But If you wanna help me with that, I can give you more detailed
instructions, how to translate and you can start with that.

Am 24.01.2013 11:53, schrieb wvengen:

Hi, is there a way to provide an English (or other) translation? I see
config/locales/en.yml but found that providing a translation there did
not translate the templates. How would this work?

—
Reply to this email directly or view it on GitHub
https://github.com/bennibu/foodsoft/issues/84.

pgp Schlüssel-ID: 0x3B2EE0A4
Fingerabdruck: 805F 73B1 9F45 4122 2FE6 ED75 0786 8427 3B2E E0A4

[wvengen]

Thanks! At this moment it's not completely clear if we will use foodsoft, but a requirement would be translation. Good to hear you're open to it. If we'll be using it, now I know how. I'll keep you posted.

[wvengen]

That seems quite a lot of work. If I can find some help, I'd like to start on it.
Is it your plan to put all translations in a single file, or use different files like mentioned in http://guides.rubyonrails.org/i18n.html#organization-of-locale-files ?

[fsmanuel]

i can help on this.
i would suggest a structure like this:

config
-- locales
---- en
------ en.defaults.yml
------ en.foo.yml
------ en.bar.yml
---- de
------ de.defaults.yml
------ de.foo.yml
------ de.bar.yml

then we have the translations separated and the filename indicates which language you are working on.
this structure is also helpfull for the implementation, because we can divide the work in parts and every part is a separate file. we should talk about how we organize this. maybe it's best if one starts from top and one from bottom (for example the views directory. you start with admin, article_categories, ... and i will start with workgroups, tasks, ...)
what do you think about it?

[wvengen]

Great! I think that's a good idea. The views directory would be most work (though I've seen some strings in ruby code as well), it makes sense to start there. Let's keep a list of how things are progressing, I've started a wiki page Translation progress. Here we could also gather things we encountered.

I've asked some other people to help me, although I'm not sure how much technical expertise will be available. I think they could make the translations, so we can focus on moving the strings to the locale files.

We could work on my repository wvengen/foodsoft/rails3, I've given fsmanual and bennibu commit rights. It should already load yml from nested directories.

Any ideas of how to split in files? One yml file per template file? We can see later how to add translations from controllers and other places. --> One file per view directory, I've put controller and model at the end of them with a preceeding comment.

[wvengen]

Just a small remark to say that we're over 1/3 of putting texts into locale files. We could use some more help, feel free to chip in :)

One thing I noticed is that there are still some erb templates floating around, and some content seems to appear in duplicate; at some point it may be nice to go through the templates, remove unused ones, and convert all to haml.

[bennibu]

wow, I am very impressed how much work you both have already put into this. Nice work!

I have no experience in translating so big projects like the foodsoft, but your approach seems to be working very well.

I promise to jump in when I finished the migration (I have to move all foodcoop installations from one host to another and ugrade to the new foodsoft). Hopefully this will be in two weeks. In the meantime, I will try not to change much in the views, so merging your fork will be easy.

[wvengen]

Thanks. I'll merge your rails3 changes back in periodically.

At some point, it would be good to have a native English speaker look over it, but as a start the current translation should be fine. How would you feel about changing "Ordergroup" to "Household"?

[bennibu]

Yeah a native speaker would definitly be a good idea. And regarding the ordergroup, I am not a fan of household, because the groups shouldn't limited to people of one flat or something. I see, in most cases this would the situation, but not in all of them. What about 'ordering group'? (This what google translate spits out, when I enter "Bestellgruppe").

[Lips]

Hello, native speaker here. I'd be happy to look over the en.* files.
Is there a preferred working method? I can fork wvengen, submit tagged (a localization tag perhaps?) issues with patches or comments, or whatever else you'd like.

[wvengen]

@bennibu maybe the use of either "ordering group" or "household" is dependant on the end-users of foodsoft, whether "ordering group" is something they can naturally relate to, or not; we can translate it using "ordering group" while maintaining a separate fork with the translation "household" for our foodcoop. I think indeed "ordering group" is better the the current translation "ordergroup" - thanks.

@Lips cool, thanks! The translation was done by a German speaker, as a Dutch speaker I've tried to remove some German-isms, and I think there's a lot to be improved. Please feel free to look over them; I suggest you fork my branch, commit your changes, and do a pull request. Then I can easily integrate them. I think the overhead of using separate issues is a bit large at this moment :o When you've done something, you could indicate that at Translation progress section 2. I could give you a login for a foodsoft instance that I keep updated from wvengen/foodsoft/rails3.

[wvengen]

Status update: i18n is done now, I expect a preliminar English translation to be finished in a couple of weeks, and hope to do a review with some people.

[Lips]

I made a series of conservative edits to most en.* files in my branch. I generally attempted to make simple typo & grammar corrections. When the context or intent was in doubt, I referred to the German, and left as-is if still unsure. Access to the instance would be helpful to double check (and improve) before pulling.

I have general concerns, but no immediate suggestions for a few broad issues:

• "Here you can.." -> Would generally be written as imperitives in English admin UIs.
• "Artikel" -> Item?
• "accounted" -> Reconciled? (Without context it's hard to say)

[wvengen]

Thanks, these are certainly improvements, and I've been so free as to pull them already (I hope that's ok).
These general things are hard. What about "Artikel" -> "Article"? That's what they are at a shop too, right?
Please let me know how I can send you a personal message for access to the foodsoft instance.

[wvengen]

I've got a technical i18n question. On several places, simple_form is used, which makes translating field values quite convenient. Now I'm using those translations in list views in a table too, as table headings. Currently, I've directly referenced the simple_form i18n namespace using t(), but it would be much more beautiful to use a helper method (e.g. allowing to fallback to default label translations).
I haven't found a proper way to do this. Or should activerecord i18n be used here instead? Would that mean double translations, one for activerecord, one for simple_form? I'm a bit at loss now.
As an example:
https://github.com/wvengen/foodsoft/blob/rails3/app/views/articles/_form.html.haml
https://github.com/wvengen/foodsoft/blob/rails3/app/views/articles/_articles.html.haml
https://github.com/wvengen/foodsoft/blob/rails3/config/locales/de/de.simple_form.yml#L84
https://github.com/wvengen/foodsoft/blob/rails3/config/locales/de/de.defaults.yml#L239 (which isn't used here)

[Lips]

The technical Q is way over my head.
"Article" alone isn't frequently used in American english. "Article of" in some cases. Item, unit (as-in SKU), and product would be much more common. Wholeshare.com uses product. I'm not sure about foodclub.org, buyingclubsoftware.com. I have a document here with the DB layout of an American wholesaler I will send to you: woof@bushwickdogwalkers.com

[fsmanuel]

@wvengen nice job with the translations!
concerning your i18n question. i pushed an example to the rails3 branch.
SimpleForm Readme reads: "In addition, SimpleForm will fallback to default human_attribute_name from Rails when no other translation is found for labels."
That means, if you specifiy it in de.defaults.yml under activerecord.attributes.article.availability and de.simple_form.yml has no simple_form.labels.article.availability SimpleForm will use the activerecord.attributes.article.availability key.
What i experienced as i tried it is that SimpleForm will first fallback to :en as a locale. So i had to delete it in the de.simple_form.yml and the en.simple_form.yml before it worked.

[wvengen]

@fsmanuel Thanks, that really helps! I'll see if I can move there what I can; some variations on labels in certain forms can then remain in simple_form's i18n.
@bennibu Do you think that is a good idea?

[fsmanuel]

@wvengen and @bennibu what has to be done to merge that into rails3 branch? we should finish this before starting with all the improvements @wvengen is planing in his fork.

[wvengen]

Currently all texts have been i18n-ized (perhaps apart from a couple I've missed, but that'll surface at some point). The English translations are not perfect, we're going through them. If you'd like all texts to be perfect before merging, I'd wait; if you accept that new features are work in progress, let's merge it now (German should be fine - although there are some tiny differences). In any case, I think a glance through the changes would be beneficial before merging - to check that we're really on the same page.

Besides that, a little refactoring would be desirable at some point - to minimise duplicate translations -, it's on our lower priority list. I don't think this is a blocker for merging.

p.s. I'm trying out localeapp http://www.localeapp.com/projects/4601

[fsmanuel]

i think we can close the issue. we should open new issues when errors surface.
@wvengen ok?