bilingual site

[hydrozen]

Hi,

I'm trying to find an e-commerce platform to use for a client of
mine's ecommerce ambitions. I am wondering if Spree supports bilingual
content. For example, i'd like products to have a description in
french and english. So it's not just the interface that needs to be
multilingual but also the actual content of the website.

Thanks for letting me know if Spree supports that kind of stuff pretty
well.

[Jones Lee]

Yes, you can achieve that, though it is not there by default. You can create YML file like this:

en:
product_<id>:
  description: sfasfasfasfkasjlkfjsa

fr:
product_<id>:
  description: sokjaslfkjasfas


and write a helper to grab the content from correct abbreviation.

--
You received this message because you are subscribed to the Google Groups "Spree" group.
To post to this group, send email to spree...@googlegroups.com.
To unsubscribe from this group, send email to spree-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spree-user?hl=en.

[Tomek "Tomash" Stachewicz]

Or you can help me with writing a Globalize3 integration extension :)

> > spree-user+...@googlegroups.com<spree-user%2Bunsubscribe@googlegrou ps.com>
> > .

[Jones Lee]

I'd love to help you out, please feel free send me email. Another approach I could think of is to create ProductDescription model:

+ lang: String
+ product_id: Int
+ description: String

Assoc: Product has 1 Description, Description belongs to Product OR you can make Descriptions belongs to many Products if you like to reuse Description for many Product (ofcourse then you have to change model structure abit)

Then write helper method product_description(product_id, lang). The lang var could be retrieved from the Session.

This approach is better because you don't have to deal with YML as main data storage.
 

To unsubscribe from this group, send email to spree-user+...@googlegroups.com.

[Tomek "Tomash" Stachewicz]

On Nov 5, 11:52 pm, Jones Lee <jonesle...@gmail.com> wrote:
> I'd love to help you out, please feel free send me email. Another approach I
> could think of is to create ProductDescription model:
>
> + lang: String
> + product_id: Int
> + description: String
>

This is basically the Globalize philosophy :)

T.

[Sean Schofield]

Keep us posted on how your extension idea works out. I think it would
be super useful.

Sean Schofield

-------------------------------------------
Rails Dog LLC
2 Wisconsin Circle, Suite 700
Chevy Chase, MD 20815
voice: (301)560-2000
-------------------------------------------

[Tomek "Tomash" Stachewicz]

First working code with docs just pushed to github:

https://github.com/tomash/globalize-spree

It's pretty crude -- translated names (descriptions etc.) can now be
done only via Rails console. Admin frontend capabilities about to
follow.

Tomash

[Tomek "Tomash" Stachewicz]

Of course issues, ideas and (preferred!) pull requests are welcome.

Tomash

[Roman Smirnov]

As far as I can remember using of Globalize greatly impairs
performance. Have you carried out measurements on this?

On 7 ноя, 22:20, "Tomek \"Tomash\" Stachewicz"

[Tomek "Tomash" Stachewicz]

Well, it's a longer topic.

Globalize1 kept all the translations in one table and therefore used
polymorphic associations (and, I don't remember exactly, but possibly
every single translated field had its own row). Which of course was
slow as hell after the number of translated stuff grew considerably.
Additionally the problem of N+1 queries (for each product on page
there was a query for getting its translated fields, each one slow
already by itself) was hard to circumvent due to mixed philosophy of
catch-all (single polymorphic table) and atomicity (each field in
separate row).
There were of course attempts to hack it:
http://www.artweb-design.de/2007/1/31/upcoming-globalize-feature-an-alternative-way-of-storing-model-translations

And this is basically the reason behind "Globalize is slow" meme.


Globalize2 (and, by extension, Globalize3 which is basically "2" but
rewritten for Rails3 compatibility allowing for cleaner code and API)
used a different approach though: every translated model had it's own
"something_translations" table, consisting of columns with translated
values (and, of course, locale for which it's used).
Which is not a very surprising design decision, provided both were
developed mostly by Sven Fuchs -- author of the blog post linked
above.

Now, theoretically the problem of N+1 queries is still here (every
single product needs a single row from product_translations), but it's
hell of a lot easier to prevent it now:

class Product
translates :name, :description
named_scope :with_translations, :include => :translations
# or even, for maximum comfort
default_scope :include => :translations
end

I've been using Globalize2 for some time now in my store -- http://bitspudlo.com
-- and using the above solution doesn't impair performance at all, the
app is super-fast.

The only question that remains is should
default_scope :include => :translations
go to globalize_spree extension into relevant class decorators?


Tomash

[Tomek "Tomash" Stachewicz]

Self-bump.

The latest globalize-spree includes some fine magic (see
"globalize_accessors" in README) for easy working with translations in
admin panel. Basically now you can edit product's name and description
in all anticipated languages on a single product form.

As for now only product form in admin has this functionality.

[David Henner]

Isn't a globalize extension best suited for a noSQL solution?  Your N + 1 queries just go away.  I'll be doing something like this on another project and i didn't even consider mySQL.  I'm going with RACK / riak.

Thoughts?

Dave

[Tomek "Tomash" Stachewicz]

> Thoughts?

One: good luck and make sure to share the code after you make it
work :)

T.