Contributions: Allow the user to set the PayPal form language

RESOLVED FIXED in 5.12

Status

addons.mozilla.org Graveyard
Developer Pages
RESOLVED FIXED
8 years ago
2 years ago

People

(Reporter: Martijn Kooij, Assigned: nmaier)

Tracking

unspecified
5.12

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729) StandardSitemap/0.1 GoogleToolbarFF 3.1.20081127
Build Identifier: 

Background:
With the current implementation of contributions via PayPal, no language gets set on the PayPal form at all (I guess). Because of that PayPal uses it's "smart" script to determine the language to be used. For me personally that will always result in Dutch (nl-NL), which not a lot of users will understand. I have had at least 4 reports from users that were unable to contribute because of this... Only when a user would first sign in on PayPal and then initiate the contribute would it "sometimes" display in his/her preferred language.

Request:
Allow us to set a fixed or default language on the "Manage Contributions" page in the Developers Hub. Using this language setting you could then modify the PayPal link/form you are submitting. This would at least give us some control over things.

ps. Not exactly the same, but related to Bug 524556, also requesting more control on the PayPal parameters.

Reproducible: Always

Steps to Reproduce:
1. Visit https://addons.mozilla.org/en-US/firefox/addon/12956
2. Click on the Contribute button, and select "Contribute $3.50" or "Contribute a Different Amount" from the drop down menu.
Actual Results:  
PayPal form is displayed in Dutch (nl-NL).

Expected Results:  
PayPal form displays in a language understandable to the user, or at worst in English (en-US).
Paypal continues to impress.  I'll try to find some docs (ha!) to tell paypal what locale to use based on what we're showing on AMO.
Assignee: nobody → jbalogh
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → 5.4
You can send "lc" with one of these country codes: https://cms.paypal.com/us/cgi-bin/?&cmd=_render-content&content_ID=developer/e_howto_html_countrycodes

Too bad we have language codes, not country codes.
(Reporter)

Comment 3

8 years ago
Doesn't AMO use the fully qualified locale code, so language-country, e.g. nl-NL, en-GB, en-US? So, without knowing anything of the AMO code, could you not simply split the country code from it, and use that as the lc parameter?
No, most of them don't have a country code:

(khan) $ ls locale
af             de             fi     it        pt_BR  sr-Latn      zh_TW
ar             el             fr     ja        pt_PT  stats-po.sh
ca             en_US          fy_NL  keys.pot  ro     sv_SE
compile-mo.sh  es_ES          ga_IE  ko        ru     tr
cs             eu             he     mn        sk     uk
cy             extract-po.sh  hu     nl        sq     vi
da             fa             id     pl        sr     zh_CN
We track locale codes because languages aren't constrained by countries' borders.  On the other hand, countries do have currencies, so it makes sense for paypal to track by country instead of locale.

> Doesn't AMO use the fully qualified locale code, so language-country, e.g.
> nl-NL, en-GB, en-US? So, without knowing anything of the AMO code, could you
> not simply split the country code from it, and use that as the lc parameter?
That's not really "fully qualified" as it is just more specific.  Languages aren't necessarily bound to regions so if a language isn't specific for that region we'll use the more generic 2 digit code.

Can these be solved by paypal?  Why is paypal choosing to display the page in Dutch?
(Reporter)

Comment 6

8 years ago
You're absolutely right, "fully qualified" is not the correct term for it. I was trying to say, that I thought that AMO used the ISO 639 language AND 3166 country codes, but I was wrong in that too, cause AMO does indeed appear to use the IETF language tag (?)

PayPal did not explain to me (after 4 emails and 3 weeks) WHY it was defaulting to nl in my case. The only thing they did tell me was that they were not able to (I read willing to) implement this, and told me to use the lc param in my form...

According to the PayPal documentation their forms should first look at a cookie (there is indeed a language cookie present for PayPal, but it expires when your session does...), and after that default back to nl. Which it obviously doesn't.

I do think that this is indeed a bug in PayPal, cause AMO does not really know that I speak nl, so AMO is not sending it. So perhaps PayPal just assumes it based on by account information there (though every single setting there is in en as well).

So, the reason why I have now requested it here is because you do have the power to force a language to the PayPal form. If it's not possible to link the IETF code to a country code, than please at least allow us to select 1 PayPal country code in the developer hub so we can at least select a language of our preference by a simple select list populated with the PayPal country codes.
I've emailed paypal, no response yet

Updated

8 years ago
Severity: major → normal
Priority: -- → P5
Still no reply
Nick is trying again.  Kicking to future.
Severity: normal → minor
Target Milestone: 5.4 → Future
(Reporter)

Comment 10

8 years ago
Any update on this still quite annoying issue?
No reply from paypal
(Reporter)

Comment 12

8 years ago
The only way I finally got a reply from PayPal about this back then was when I posted the problem through their PayPal Merchant Technical Services page:
https://ppmts.custhelp.com/cgi-bin/ppdts.cfg/php/enduser/home.php
Never got a reply to any of my emails about this, only got a link to that support page after opening an official complaint.
Alright, we just got off the phone with paypal.  Their documentation is out of date and apparently their language detection order is:

lc parameter
paypal cookie
merchant email extension
en-US

In this case, your email ends in .nl, so everyone sees the Dutch page (!).  They say there is a parameter (similar to lc) that we can set to override the choice and they'll send it our way as soon as they update the docs.
(Reporter)

Comment 14

8 years ago
Just for the record.
After reading your message, I though I had a nice workaround until an actual solution comes available: Just change my PayPal's primary e-mail address into something not .nl. So I did, changed it to a .com address, but still it displayed in Dutch. I Even removed my .nl address from PayPal, which did work cause I could not even login using it any more, but still the contribute page was in Dutch... SO I guess they store the address and/or extension somewhere when the account is created and use that forever after...

I'll wait patiently again.
Changing to a .com address will work as you expect.  You'll need to clear your paypal cookies before visiting the page.
(Reporter)

Comment 16

8 years ago
Sorry about that, I must have missed a cookie. Just tried it again, on a clean Firefox profile just to be sure, and finally, PayPal is talking English to me.
(Reporter)

Comment 17

8 years ago
I have contacted PayPal support again to explain the email address workaround cause this morning all was Dutch again, didn't change anything. I'll post any answer here so other developers might be helped by the workaround as well.

Comment 18

8 years ago
I also tried to change the email address like Martijn, but unfortunately it didn't work.

I think that the best way would be for AMO to force in PayPal the same language as the add-on details page; it will make for a better user experience, IMHO.
I've always had a .com email address, but contrarily to what has been reported here it *has no effect* in the default language outcome. Maybe you need a .co.uk or a .us email address to change it? Either way, it's brain damaged.

In my case at least (.com email address since the beginning), PayPal falls back to the language of the country where your account has been "assigned to" by the management, e.g. Paypal Italy in my case. It's a business/ bureaucratic detail, not a technical one, and there's apparently no way at all to change this default unless you open a new account giving fake address details (and, aside the possible criminal offense, you'll probably have great pains at withdrawn your money, unless you've got also an offshore bank account). 

So this bug badly needs to be fixed, otherwise the contribution feature becomes much less useful for developers who are not US or GB residents.

The obvious drawback of forcing the lc parameter is that users who already have a different preference set through a cookie won't get what they expect, but if we provide sensible values according to current AMO chosen locale, this becomes almost a non-issue.

Therefore I propose using the following simple mapping function (PHP, but a Python porting, if needed, would be trivial) to set the lc parameter for contribution PayPal transactions:

<?php
/**
 * Translates a language code to a country code
 * @param   string $ln language code (en-US, zh-CN, el, xx)
 * @return  string $lc country code (US, CN, GR, US)
*/
 
function ln2lc($ln)
{
   static $map;
   
   $parts = explode('-', $ln);
   
   if (count($parts) > 1) 
      return $parts[1];
   
   if (!isset($map))
   {
      $map = array(
         'af' => 'ZA',
         'ar' => 'EG',
         'ca' => 'ES',
         'cs' => 'CZ',
         'cy' => 'GB',
         'da' => 'DK',
         'de' => 'DE',
         'el' => 'GR',
         'eu' => 'BS',
         'fa' => 'IR',
         'fi' => 'FI',
         'fr' => 'FR',
         'he' => 'IL',
         'hu' => 'HU',
         'id' => 'ID',
         'it' => 'IT',
         'ja' => 'JP',
         'ko' => 'KR',
         'mn' => 'MN',
         'nl' => 'NL',
         'pl' => 'PL',
         'ro' => 'RO',
         'ru' => 'RU',
         'sk' => 'SK',
         'sq' => 'AL',
         'sr' => 'CS',
         'tr' => 'TR',
         'uk' => 'UK',
         'vi' => 'VI',
         );
   }

   return isset($map[$ln]) ? $map[$ln] : 'US';
}
?>


This provides reasonable country codes counterparts for all the language codes listed in comment 5, is relatively easy to extend with other locales (e.g. with the help of http://www.i18nguy.com/unicode/language-identifiers.html and https://www.x.com/docs/DOC-1154 ) and will fallback to US English in corner situations (which I can't imagine ATM, though).
Severity: minor → normal
(Assignee)

Comment 20

8 years ago
Created attachment 450893 [details] [diff] [review]
v1, based on Giorgio's code, add an lc

Code is simple, but untested within remora, as I fail to setup remora on my devbox (no good testdata available, only outdated stuff).
Instead I tested in tiny test script.

DownThemAll! also "suffers" from this issue. We have a downthemall.net address which is associated with a paypal account registered in Italy. The default language hence is Italian for all users.
Attachment #450893 - Flags: review?(jbalogh)
(Assignee)

Comment 21

8 years ago
PS: The issue was reported more than half a year ago and likely affects the "income" of all addon developers from outside the us/uk.

Hence, please make this a priority! (You've got a patch now ;)
I was getting something non-english on https://preview.addons.mozilla.org/en-US/firefox/addon/201/ before this patch.

r70203.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: Future → 5.11.4

Updated

8 years ago
Attachment #450893 - Flags: review?(jbalogh) → review+
Verified FIXED on https://preview.addons.mozilla.org/en-US/firefox/addon/201/ and https://preview.addons.mozilla.org/en-US/firefox/addon/12956
Status: RESOLVED → VERIFIED
It's broken again :( 
Needs to be ported on Zamboni? sigh!
Status: VERIFIED → REOPENED
OS: Windows XP → All
Resolution: FIXED → ---

Updated

7 years ago
Priority: P5 → --

Updated

7 years ago
Duplicate of this bug: 502924
(Assignee)

Comment 26

7 years ago
Created attachment 475630 [details] [diff] [review]
patch v2, for zamboni

Same as for remora this time for zamboni.

Again untested, as there is no test data for zamboni readily available, and I was to lazy to ask for some or create some myself :p
Assignee: jbalogh → MaierMan
Attachment #475630 - Flags: review?(jbalogh)
(Assignee)

Comment 27

7 years ago
This is a regression now, isn't it ;)
Severity: normal → critical
Keywords: regression
Hardware: x86 → All
Target Milestone: 5.11.4 → ---
Thanks! I cleaned up the style and added a test: http://github.com/jbalogh/zamboni/commit/bcbc48a.

(This never went live so it's not a regression.)
Severity: critical → normal
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago7 years ago
Keywords: regression
Resolution: --- → FIXED
Target Milestone: --- → 5.12

Updated

6 years ago
Attachment #475630 - Flags: review?(jbalogh)
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.