Improve 'customer-only' shopfront messaging

[sstead]

Description

Fir private/"customer only" shops, the default messages for non logged-in users and UX is confusing.
We need to rephrase the messages for UX under the signup process.

Current and Expected Behavior

1- When a visitor is not logged in and open the url of a private shopfront:

BECOMES:
Only approved customers can access this shop.
If you're already an approved customer, login or signup to proceed.
Want to start shopping here? Contact SHOP NAME and ask about joining.

2- When a visitor is logged in and open the url of a private shopfront but is not part of the customer list of the shop:

BECOMES:
Sorry, only approved customers can access this shop.
If you'd like to start shopping here, please contact SHOP NAME to ask about joining.

Steps to Reproduce

1. Make sure user A is not part of shop A customer list
2. Not logged in, user A open url of shopfront A, you see message 1 above.
3. Then logs in and recharge the shopfront page. you see message 2 above.

Severity

S3 as UX is pretty bad now

[enricostano]

Is this valid for hubs also? In the case of a buyers group the concept of customer should map to member or something like that. Any thought?

cc/ @sseerrggii

[myriamboure]

@enricostano @sseerrggii I guess you can rephrase for your instance. I would personnally rephrase more like "only authorized shoppers can access this shop" on French instance, so that it works both for "customers" or "members", they are all "shoppers" (or buyers?) and that's try that "member types" shoppers don't like to be called "customers" or "clients". What do you think @sstead ?
I think we can ask some of our new super efficient volunteer devs to take care of this one but just want to confirm the above English text. If your "member type buying group hubs" are happy with being called customers @sstead I guess you want to keep that text? Please confirm :-)

[myriamboure]

@sstead can you confirm givern my latest comment? It's the kind of easy good first issue we can have a new dev working on quickly, just want to make sure it is well specified ;-)

[sstead]

I don't have much preference regarding word choice between approved/authorised or customers/shoppers . I'd prefer to avoid using the word 'members' by default on the Aus instance - few shops have membership requirements.

[myriamboure]

Ok, no worries then let's just keep it as it is for English master, then people can adapt on their own English locals.

[tmcjunkinmarquis]

Hi, I am working with @RyanH5. You communicated with him about issue #1255. You also suggested 4 alternate issues for us. For this issue, we have looked through the app and cannot find "a url of a private shopfront" in order to reproduce the behavior before we attempt to refactor. Can you tell us how to find an example url of a private shopfront. Thank you for your help!

[sstead]

@tmcjunkinmarquis , I've set this shop on Australia's production site to be private- https://openfoodnetwork.org.au/demo-hub/shop . Let us know if you need anything else :)

[tmcjunkinmarquis]

We were not able to reproduce this problem locally and unfortunately we can not continue working on it right now. Thank you for your quick responses!!

[deanmarc25]

Can I pick this up as a first issue? I will be working on setting up the project locally this week and will see if I can get this to work for the team.

[daniellemoorhead]

Go for it @deanmarc25, and welcome! 😄

@sstead can help you out with detail if you have any trouble with it, and just ask for tech assistance on the dev channel on slack if you need it!

[RachL]

@luisramos0 @mkllnk @sigmundpetersen I'm not sure I've followed everything, but I thought I understood that now English is translated through Transifex as well, am I right? So this issue can be dealt by translator directly, correct?

[sigmundpetersen]

Well afaik UK, US and CA are using en_GB.yml, en_US.yml and en_CA.yml locales respectively and can edit the strings through Transifex. But AU is using the source locale en.yml and the strings here have to be updated through a PR.

[RachL]

That seemed too easy :-) Thanks @sigmundpetersen

[luisramos0]

since en_AU is in transifex, this can be done in transifex here:
https://www.transifex.com/open-food-foundation/open-food-network/translate/#en_AU/enyml/80855218?q=key%3Arequire_login_html
https://www.transifex.com/open-food-foundation/open-food-network/translate/#en_AU/enyml/80855217?q=key%3Arequire_customer_login
and here:
https://www.transifex.com/open-food-foundation/open-food-network/translate/#en_AU/enyml/80855219?q=key%3Arequire_customer_html

I am closing the issue as we dont track transifex work in gh, but please re-open if you want to track this one.

[mkllnk]

I think we should distinguish between locale specific changes and changes that make sense for every locale. For example if there is a typo in the English source locale, we should fix it. Otherwise every English instance has to fix it separately or it's overlooked or translators simply get confused.

The changes Sally proposed here go beyond a simple text change. They also include an additional link which cannot be added by a translator. The changes also make sense for all instances.

I'll re-open this issue.

[luisramos0]

Hello @mkllnk
I am not sure I understood your point. Are you suggesting we make these changes in the en.yml as well?

[mkllnk]

Yes, I think this task involves changes in en.yml and other parts of the code. It can't be solved in Transifex alone.

Additionally, the changes make sense for all instances. Changing en.yml will trigger people to translate this and have a better message than before.

[luisramos0]

thanks @mkllnk, you are right! I missed the variables in the translation strings.
I went for it. Please see PR #3932