Multilingual Plugin


#1

I’m releasing my big multilingual plugin. It was originally based on
Per Wigren’s MLR code, but it’s been redesigned and written from
scratch, under the MIT License. This is the first public release, so
although it passes all the unit tests, I expect there to be some
glitches.

Here’s what it does:

* Simple to use.
* Translates both db content and view text.
* Supports automatic selection of an alternate, localized template

for each view.
* Built-in localization and translation of strftime, numbers, and
currency formats.
* Supports pluralization.
* All data is stored in three, automatically migrated, database
tables.

Installation

  1. script/plugin install
    https://OpenSVN.csie.org/multi_lingual_rails/multilingual/trunk
  2. script/generate multilingual (generates a new migration)
  3. rake migrate

See the wiki at:
https://opensvn.csie.org/traccgi/multi_lingual_rails/trac.cgi/wiki

RDoc will be available as soon as I find somewhere to upload it.


#2

Joshua Harvey wrote:

* Supports automatic selection of an alternate, localized template
  1. script/generate multilingual (generates a new migration)
  2. rake migrate

See the wiki at:
https://opensvn.csie.org/traccgi/multi_lingual_rails/trac.cgi/wiki

Congratulations,

boy, this is good news. The feature set looks “really” nice. Can’t wait
to
try it and see it mature.

Sascha E.


#3

Thanks merci grazie danke! :slight_smile:

Il giorno 22/nov/05, alle ore 13:10, Joshua Harvey ha scritto:


#4

Hi

Installation

  1. script/plugin install
    https://OpenSVN.csie.org/multi_lingual_rails/multilingual/trunk
  2. script/generate multilingual (generates a new migration)
  3. rake migrate

After the first step, I’m getting the following message when I try to
start
the server:

aroedl@hydra ~/user/qasar11 $ ./script/server
=> Booting WEBrick…
/usr/lib/ruby/gems/1.8/gems/activesupport-1.2.3/lib/active_support/dependencies.rb:200:in
`const_missing’: uninitialized constant CoreExtensions (NameError)

from
./script/…/config/…/vendor/plugins/multilingual/lib/multilingual/localization/core_ext_hooks.rb:4
from
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in
`require’

from
/usr/lib/ruby/gems/1.8/gems/activesupport-1.2.3/lib/active_support/dependencies.rb:214:in
`require’

from /usr/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/initializer.rb:315:in
`load_plugin’

from /usr/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/initializer.rb:315:in
`load_plugin’

from /usr/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/initializer.rb:306:in
`load_plugin’

from
/usr/lib/ruby/gems/1.8/gems/activesupport-1.2.3/lib/active_support/core_ext/kernel.rb:27:in
`silence_warnings’

from /usr/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/initializer.rb:306:in
`load_plugin’
… 10 levels…

from /usr/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/commands/server.rb:28
from
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in
`require’

from
/usr/lib/ruby/gems/1.8/gems/activesupport-1.2.3/lib/active_support/dependencies.rb:214:in
`require’
from ./script/server:3

As soon as I remove the multilingual from the plugins directory,
everything is
fine. I can’t actually get a clue from the error message… :frowning:

Ruby 1.8.3
Rails 0.14.3
Active Record 1.13.0
Action Pack 1.11.0
Action Mailer 1.1.3
Active Support 1.2.3
AWeb Service 0.9.3

Andreas


#5

Hi Joshua,

The feature list looks great!

I haven’t seen the String division operator used before. The pickaxe
book
has a reference (
http://www.ruby-doc.org/docs/ProgrammingRuby/html/ref_c_string.html#String._pc)
to the % operator for String formatting but I can’t find any references
to
/. How does this work?

Thanks


#6

±le 22/11/2005 14:10 +0200, Joshua Harvey a dit :
| 2. script/generate multilingual (generates a new migration)

That phase is a bit too MySQL centric, you can’t do that kind of insert
with
other databases.


#7

Hi Joshua,

Joshua Harvey wrote:

I’m releasing my big multilingual plugin.

* All data is stored in three, automatically migrated, database tables.

You made a great work.
If I can make a small reserve, I’m not convinced by the db design
retained. Storing (table_name, field_name, value) for each translatable
field seems not to be the best way, though for sure it’s a good way to
‘multilinguize’ a legacy app.
The better way would be to change

TABLE
id
field1
field2
translatable_field1
translatable_field2

into

TABLE TABLE_translations
id <------\ id
field — main_model_id (belongs_to TABLE)
lang
translatable_field1
translatable_field2

It’s cleaner imho.
I think such migration would be possible with a script that would
analyze models.

Is there a reason why you didn’t retain such design ?

Jean-Christophe M.


#8

Nice one, this is a great start. I am very much looking forward to
trying this out in the next couple of weeks.

Database thoughts:

It’s late and I’m tired but why not something like:

LANGUAGES
id
country_code
currency_things
time_things

PHRASES
id
original_phrase_to_be_translated

TRANSLATIONS
id
language_id
phrase_id
translation

Then you can do things like

PHRASEGROUPS
id
phrase_id

for nice translatino admin such as 'these are all the phrases for
mymodel.rb/.rhtml myothermodel.rb/.rhtml


#9

Hi, Joshua,

really great news. Thanks a million!

Regarding the RDoc: What do you need for that? Just some upload space? I
think that would be no problem, just give the list a note (or write
directly to removed_email_address@domain.invalid) what your requirements are…

regards
Jan P.


#10

Jean-Christophe M. wrote:

field seems not to be the best way, though for sure it’s a good way to
into
analyze models.

Is there a reason why you didn’t retain such design ?

I am inclined to agree with that. Can you explain why you did that? I
mean,
what was you motivation to do it that way? I would tend to just use a
field
extension:

TABLE
id
field
field_de_DE
field_en_EN
field_fr_FR

The problem is that this would probably make the table definitions
harder
to maintain, but, it would certainly be more performant. The logic would
be
easier. It would also be easier to index (create indices).

Abstracting out this logic so early seems a little like premature
optimization.

Please enlighten us.

Sascha E.


#11

congrats for great work. thats fabulous. is there any plans for making
the
translations file cached? I mean without needing db access?