Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

[Feature] All output presented to user should be translatable. #1378

Closed
tvdeyen opened this Issue · 28 comments

8 participants

@tvdeyen

In order to become "The No. 1 e-commerce layer in the internet" every single output presented to the user, either in the admin and in the store views should be translatable and localizable.

This is not the case right now. So nowadays we have to monkey patch methods and override views, so they become translatable. We all are aware of the spree_localize and the spree_globalize gems. They are great, but the core has to be translatable, so these projects can do their work even better.

And related:

  1. The translation keys should be scoped into spree namespace (#1377)
  2. And the translation keys should additionally be scoped into their context. Examples:
    1. t(:add) is not a good translation key
    2. Neither is t(:checkout). Better would be t(:checkout_headline, scope => 'store.views') or something similar.

I know, this is a bunch of work. But I really think this is an important step for Spree to become a global player.

@radar
Collaborator

Even though that this is a feature request and our usual policy is to shut them down as soon as they crop up (but still note it down, in case someone else asks about it), I think this is actually perfectly valid. We could look at bringing these changes in 1.2.

@jumph4x

@radar Ahahahahahaha

@tvdeyen

this is a feature request and our usual policy is to shut them down as soon as they crop up

@radar You are kidding me, right?

@radar
Collaborator

No, for real. We have feature requests all the time to Spree and if we have just one or two people requesting them, how is that worth the investment of our time to introduce them? Why can't those people just release those features as extensions to Spree?

But if we have a whole group of people (its size an arbitrary number between 3 and infinity) and we think the feature would be a good fit for Spree, we'd implement it. An example of this would be the VAT work that @schof did that went into 1.0.

@tvdeyen

Ok, I totally understand that.

But hopefully a lot of the spree core team agree with this issue. I offer my help, although I have a bunch of work on my own.

But hey, I like spree.

@jefferyf

While I agree that this would be a good feature to consider including in Spree I'd like to add my perspective: in having worked on several implementations of Spree for clients, all of them required extensive, sometimes radical modifications. Clients are all just special snowflakes, y'know? I've never worked on a Spree site that had fewer than five extensions installed, and I've never worked on a store that wasn't totally modified from the default store layout. I'm usually required to modify existing extensions to suit my specific needs.

My point is, even if Spree did include this in core, you'd still have to make sure that all of the extensions you write, or use or modify are completely internationalized if/where appropriate.

I would totally encourage Spree to take a look at it, but they do have limited resources and I guess my feeling is that since modifications to Spree are essentially required for each client (or store), so each developer bears the responsibility of covering extensions. Spree's making it easier and easier to create extensions, which is an awesome thing.

@schof
Owner

We do our best and the more people ask the more we can develop a sense of the true urgency of the problem. In the meantime we are happy to give people helpful feedback and even sometimes some suggestions on how you can achieve the desired result yourself.

Since we need a way to focus on actual bugs we mark this type of stuff as feature and close it out. Its not personal, its just a realistic acknowledgement of our limited capacity to deal with things. It also makes the list of issues manageable so that we can focus on actual bugs vs. features. NOTE: Github does not differentiate and we need to keep the open list small so we can find them.

@schof schof closed this
@schof
Owner

We can filter by labels but beyond that there's no additional way to prioritize things. Also, having 200+ open "issues" has already been misinterpreted by some as Spree having a lot of bugs. It also impedes new contributors who want to work on known issues. Finally leaving issues open but labeling them as features gives the impression they will be acted upon in the near future.

@steveh

How about a "wishlist" wiki page? Things you agree would be good to include in spree core but have no plan on actually doing in a specific timeframe.

If certain features have an "official" blessing that they would be good to be included it may motivate other developers to take a punt at implementing them (wasted effort if the spree committers don't like the idea in the first place)

@lafeber

A feature request (wish) list would be a very good idea. We're missing something that people can vote on. Good i18n support would definitely get my vote!

@jipiboily

I agree with @lafeber that a feature request list or something like that would be great. Maybe something like User Voice?

It could even be useful for community developers that need some feature as they would know if there is a real need for feature X or Y. If you know feature X have 200 votes, it might be interesting to develop an extension and make a call on the mailing list or whatever to get some help, if needed.

My 2 cents.

@tvdeyen
@radar
Collaborator

I would really love to see some kind of organised effort in translating Spree. The problem that I see at the moment is that we English speakers modify the English translations and that means that the other translations lag behind. There's no easy way at the moment to see what translations need updating or to get in touch with people who are those translators, and so we depend on the community to point out when there's issues with translations and to submit patches to spree_i18n to fix those translation issues.

Perhaps using something like tolk would assist?

@lafeber

I've noticed that the translations weren't complete. Within a few weeks, I'll fix the translations for nl, de, and fr.

@radar
Collaborator

I think the i18n translations are presented in a non-human-friendly manner. They are structured like this:

en:
  some_label: "Some label"

When it's much more sensible (imo) to structure them like this:

some_label:
  en: "Some Label"
  fr: "Une Étiquette"

Or something like that. I could be crazy, but in my head this is how it makes sense.

@tvdeyen
@radar
Collaborator

The best way to do that is to go through and find these places and flag them, either with issues (bad) or pull requests (good).

@tvdeyen
@radar
Collaborator

Putting them inside a namespace would be great:

en:
  spree:
    some_label: "Some label"

For instance.

I think all the translations are currently not done this way. This would be the best place to start.

@tvdeyen
@radar
Collaborator

Yes, all existing translations should be updated so that instead of:

I18n.t(:some_label)

We would have:

I18n.t('spree.some_label')
@tvdeyen
@radar
Collaborator

Sure, that'll work. Do that.

@tvdeyen

Aye, aye sir. Have three releases this week. So I will look into that next week.

@radar
Collaborator

Any news on this @tvdeyen?

@tvdeyen

Not yet, sorry. Too busy. But I haven't forgot.

@tvdeyen

@BDQ @radar reopen this issue? @schof still not convinced? If not, please join the discussion in the google groups. Thanks, :heart:

@radar
Collaborator

No, not going to reopen this issue because it is a feature request and has no clear end goal in mind. It is a constantly evolving thing. It'd be like having a ticket open for making core "the best e-commerce platform ever".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.