Can we remove #populate from the api?

[Sven Fuchs]

I might be wrong but it just occured to me that now that we have
support for loading translations form both Ruby and Yaml files
I18n.populate does not make so much sense any more.

The reason why we invented this in the first place was that we thought
that we'd need to a) use plain Ruby Hashes for translations and b)
could not directly return these from a Ruby file. So we thought we'd
need to give a backend that manages its own state (like a db backend)
the chance to decide whether it wanted the translations to be actually
loaded or not:

# during startup
I18n.populate do
require 'translations.rb'
end

# in translations.rb
I18n.store_translations 'en-US', {:foo => 'foo'}

This way any backend could decide whether or not it wanted to yield
the block passed to I18n.populate and the require statement to happen.

We now can use both

I18n.load_translations "translations.rb"
I18n.load_translations "translations.yml"

with translations.rb then containing just the translations Hash (and
no call to I18n.store_translations).

So if we make sure only the latter would be used during, e.g., Rails
framework loading process I can not see what sense I18n.populate would
make anymore.

Am I missing something?

I'd otherwise suggest to remove the method from the API to make it
simpler.

--
sven fuchs sven...@artweb-design.de
artweb design http://www.artweb-design.de
grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone)
d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)

[jos...@gmail.com]

I agree. I think we can drop "populate" and also "store_translations"
from i18n. These were always a little confusing, and were only used in
the Ruby locale files. Now that we're just eval-ing a Ruby hash in
those files, we don't need them.

We can keep "store_translations" in the SimpleBackend, but not in the
i18n API. This might be useful for testing SimpleBackend.

It would be great to hear from everybody else, especially if you're
using either of these methods in your code.

-- Josh

> sven fuchs svenfu...@artweb-design.de

[Sven Fuchs]

Ok, yeah.

It seems reasonable to play a bit defensive here. If we find that
custom backends really need other ways to store something besides
#load_translations we can always open I18n and monkey-add them
experimentally and then cherry-pick good solutions in our next Rails/
I18n dev cycle.

If we want to do it we should do it quickly though because we need to
update quite some places.

I hope I'll find some time to look into that tomorrow.

--
sven fuchs sven...@artweb-design.de

[Christian Rishøj]

Keeping Backend#store_translations as a uniform way to fill a backend
with translation makes a lot sense to me.

Also, it would be nice with a way to extract translation templates
(possibly within some scope) from a backend.

Christian

[Joshua Harvey]

My problem with Backend#store_translations is that it wouldn't be so uniform. SimpleBackend would simply store the translations in the current process, so this wouldn't be persistent, and wouldn't even update other Rails processes. A db backend might store the records persistently to the db. I don't think the semantics of the method are well-defined yet, so this is something I'd want us to work out for the next release.

I didn't quite get the translation template part, could you elaborate on that, Christian?

-- Josh

[Christian Rishøj]

On 26 Aug 2008, at 22:48, Joshua Harvey wrote:

> My problem with Backend#store_translations is that it wouldn't be so
> uniform. SimpleBackend would simply store the translations in the
> current process, so this wouldn't be persistent, and wouldn't even
> update other Rails processes.

Ah. I was mistakenly assuming that #store_translations was supposed to
actually persist translations in backends apart from Simple.

> I didn't quite get the translation template part, could you
> elaborate on that, Christian?

I am hoping for a way to dump/restore translations from/to a backend,
in a well-defined format. The current Hash-format seems fine.

I imagined #store_translations could do the restore job. To extract/
dump stored translations from a backend, another method would have to
be added, e.g. #dump_translations.

The expression "translation template" was chosen to make it explicit
that the dump method returns the "raw", un-interpolated translations,
as opposed to #translate. Sorry for any confusion caused by this
misnomer.

With the above set of methods available on the backends, it would be
possible to e.g. migrate translations from one backend to another.

It would make sense to be able to restrict the methods to a certain
scope – i.e. tell the dump method to "dump everything below en-
US.date", or tell the restore method to "place the given translations
under the scope en-US.date". Could be:

Backend#dump_translations( scope = '' )
Backend#restore_translations( translations = {} , scope = '' )

or

Backend#dump_translations( locale, scope = '' )
Backend#restore_translations( translations = {} , locale, scope = '' )

Makes any sense?

Christian

[Joshua Harvey]

Yep, totally makes sense now. I agree that loading and dumping translations into a well defined file format will be very useful for many uses, including synchronizing apps for deployment, and reusing translations among apps. This might even be a worthy feature for i18n in Rails, but I think we're too close to release of the first version to consider this now. Let's try it out in plugins and see if we can integrate it into i18n for the next release.

-- Josh

[Sven Fuchs]

Ok, I've removed #populate and #store_translations from I18n now and
removed #populate from the Simple backend.

http://github.com/svenfuchs/i18n/commits/master/lib
http://github.com/svenfuchs/rails/commits/i18n

I've also posted a pull request to Rails' lighthouse

http://rails.lighthouseapp.com/projects/8994/tickets/912-i18n-remove-populate-and-store_translations-from-the-public-api

... and already notified some of the demo-app and tutorial authors.
I'll continue to do that later today or tomorrow.

--
sven fuchs sven...@artweb-design.de