Add I18n support

[ghost]

spree_static_content would provide greater support for international shops if the extension supports spree_I18n. Especially I'm lacking translations of paths for a static page, e.g. '/welcome', '/willkommen', '/bienvenue'.

One way to handle this is to create several pages, which makes updating through tools like Locale a clunky job. The spree products creation process is a good role model for creating a static page with translations:

• add static page first through backend
• click on (missing) button 'translations'
• add translation for all fields, such as title, path, contents, etc.

What is your opinion about the idea? How do you guys handle static pages and I18n?

[nunopolonia]

I implemented the i18n support in my fork of this gem (https://github.com/nunopolonia/spree_static_content) It works exactly as you describe but in order to do it it adds spree_i18n as a dependency which is a big gem. If the core team feels it makes sense to have it by default, I can make a pull request. If not, perhaps it's better to extract this functionality into a gem of it's own like spree_static_content_i18n or something like this.

[j540]

@nunopolonia , It would be great to also have a translation for the 'LAYOUT' field

[nunopolonia]

@j540 can you open an issue on my fork and I will implement it ASAIC?

[j540]

I must be missing something, but it seems that issues are disabled on your fork.

[nunopolonia]

You're right @j540. They're up now

[futhr]

@nunopolonia nice i18n support in your fork, the problem is just how to deal with the migration if someone don't want to use spree_i18n. The rest of the code can be conditionally applied. Spree i18n gem use Globalize that is good if you need to support a lot of languages, for regular Rails projects with 2-3 locales I prefer traco gem to avoid the extreme n+1 queries that comes with Globalize (and many other chained issues that comes with it).

But I think this gem can be more globally useful if it has i18n support per default and use spree_i18n as a runtime dependency. What you think @peterberkenbosch ?

[francesco-carrella]

Hello, any chance to see @nunopolonia code in the main repo?

[lucamonfredo]

:+1: on this one. Please add support for spree_i18n and spree_globalize. ping @futhr , @nunopolonia : any news?

[futhr]

Hi, spree_i18n seems to be in status of some major changes where the globalize part probably going to be extracted to its own gem but its still unclear related to how and when. The commits in @nunopolonia's fork are a good starting point, but there are lots of other work that has to be done to make it mergeable. If anyone up for it you welcome to cherry pick his commits and continue the labour.

[Whelton]

Hi all, encountered as I wanted to use in my localised Spree store.

Thank you @nunopolonia, your work was a great starting point and I just forked the latest of this repo, copied his changes, then did some relevant tweaks to the versions I use in my project:

• spree/spree@5c6d69dfed60722b89f5d42d63707ad00e3db1c2 (3.1.0.beta)
• spree-contrib/spree_i18n@5e68c1ac7baeae566f0c48a72aca2ba1f5e1ec12
• spree-contrib/spree_globalize@f4dd991390eae7741f9950ea3360fb44d24c0294
• spree-contrib/spree_static_content@727f257f62e948fe8c7e5b790c90361faf4898e5

You can see here my fork here: https://github.com/Whelton/spree_static_content

To update anyone else, they abstracted the model translation bits out of spree-contrib/spree_i18n and put them in a separate gem spree-contrib/spree_globalize

The only caveat I can see is that in my version of spree_globalize the namespace is Spree::Globalize, however that was recently changed to SpreeGlobalize, as of this PR merge spree-contrib/spree_globalize@8c6546f2b464343f7982f0dca33a8859d58800e2

Happy to make an update to be good with SpreeGlobalize master and make a PR, if others like!

[futhr]

Nice work @Whelton