spree_i18n: Variants select and products search not working any more.
First I thought this is only an issue in the variants select in the “admin new order” view (https://github.com/spree/spree/issues/6146).
After researching I realized that currently the complete product search is broken since Globalize 5 does not set the original value anymore.
So, instead of:
Spree::Product.search(name_cont: 'brand')
we need to call:
Spree::Product.with_translations(I18n.locale).search(translations_name_cont: 'brand')
This means, we have to decorate all admin controllers AND deface all admin form fields that contain translated values 😱 This seams way to hackish for me.
Maybe it’s time to merge the globalize feature into spree core? :trollface:
Seriously, we currently force all spree_i18n users to also have globalize in their project anyway, although they don’t always need it. spree_i18n was once a repository for translation files only, not for multi language stores.
Since this “fix” needs to be deeply integrated into spree_core, I think it is better integrated into the core.
Spree has a global foot print by now 🙌 and is used all over the world. Does the globalization feature harm existing users? I don’t think so. IMHO it is more harmful to maintain an extension that patches so many core files, like we need to do now.
So, let’s split up spree_i18n into two pieces:
- The translation files stay where they always where.
- The globalization feature gets merged into core.
What do you think?
About this issue
- Original URL
- State: open
- Created 9 years ago
- Comments: 50 (41 by maintainers)
@tvdeyen any chance you could give a try on spree_i18n/ransack-translations branch please? (see PR above)
If I got this right the issue lies in ransack not knowing anything about globalize, the original ar api e.g.
whereseems to be working fine so perhaps if we tell ransack about the translations we could fix this in one place only.About having globalize into spree core … just please dont. I find spree an extremely complex project (itself and all of its dependencies mokey patching one another) and throwing globalize there wouldn’t be fair given most stores will never need to translate on db level (will they?). I’d definitely agree though that having globalize here could be misleading mainly for beginners so yeah splitting globalize and the locales logic here sounds pretty awesome.