Questions indirectly activated for locales different from activated ones (en-US, pt-BR)

RESOLVED FIXED in 2013Q3

Status

support.mozilla.org
Questions
P1
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Scoobidiver (away), Assigned: mythmon)

Tracking

unspecified
2013Q3

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: u=user c=aaq p=1 s=2013.19)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Bug 827650 activated two support forums, en-US and pt-BR but it also makes localizable question strings in any locales and the UI is indeed localized once Verbatim is updated.

So currently, the Dutch, German, Italian, Chinese, Spanish, Russian, Fufula, and Japanese support forums (see https://localize.mozilla.org/projects/sumo/) are indirectly activated, either for a Google search or the Get Community Support page for some locales, although users post in the English support forum.

With more locales localized, there will be more and more non English threads in the English support forum. See https://support.mozilla.org/fr/forums/contributors/70901 that started on February 28th (the question UI has been localizable since February 20th).
(Reporter)

Comment 1

5 years ago
> https://support.mozilla.org/fr/forums/contributors/70901
My bad. I meant https://support.mozilla.org/forums/contributors/709017

In addition to web searches and wrongly localized Get Community Support pages, users may replace manually the /en-US/questions/new in any localized Get Community Support pages  by /<locale>/questions/new thinking the en-US is an error.

The solution would be to redirect non activated locales to en-US for questions.
Kadir, thoughts on what to do here?
Flags: needinfo?(a.topal)
(Reporter)

Comment 3

5 years ago
See also bug 778437 comment 27.
(In reply to Scoobidiver from comment #1)
> The solution would be to redirect non activated locales to en-US for
> questions.

That solution is reasonable to me. Something like `if request.locale not in settings.AAQ_LOCALES: redirect('/en-US/questions/new')`.

Kadir?

Comment 5

5 years ago
That would basically remove the AAQ flow in other languages, but it would not remove the access to it, generating some oddities across the user navigation. 

I think that the solution to this problem comes from giving locale leaders the opportunity to create a pointer to external forums (like Mozilla Hispano, the French community, etc).

If that pointer is empty and as you say request.local not in settings.AAQ_LOCALES...don't show the AAQ link or the box for community support.
(Reporter)

Comment 6

5 years ago
(In reply to Ibai Garcia [:ibai] from comment #5)
> I think that the solution to this problem comes from giving locale leaders
> the opportunity to create a pointer to external forums (like Mozilla
> Hispano, the French community, etc).
This solution is the current one for big locales with /kb/get-community-support either containing a link to the localized support forum (German, French, Italian) or redirected to it (Spanish). For others (no localized support forums or page not localized), the link in /kb/get-community-support is /en-US/questions/new.
The Spanish solution may be perturbing for some users as there are redirected from SUMO to an external website not containing mozilla.org in its URL without any warning (seems an hijack). The "Get Community support" page seems better to me because it's a buffer and prevents also duplicated questions with a link to the forum search.

Nevertheless, with all this safety, there are still questions in languages different from English because "smart" guys replace en-US by their locale to "activate" the localized support forum.

Comment 7

5 years ago
Right Scoobi. I think the main difference is to remove any type of access to the AAQ for other locales.

And another piece of knowledge: for AAQ in non EN or PT languages, the main access is through the language picker. The workflow seem to be similar like to this:

- User lands on the AAQ flow in English (haven't investigated much why).
- User wants to ask a question on it's own language, so she chooses the language picker and changes the language to her own.
- User lands on the AAQ with a language that is "not supported".

That calls for a removal of the Language picker on the AAQ, maybe?
(Reporter)

Comment 8

5 years ago
https://support.mozilla.org/users/auth links to /questions/new which will present the localized AAQ.
(Reporter)

Comment 9

5 years ago
It's also linked to from article discussions. See https://support.mozilla.org/fr/kb/utiliser-java-bloque/discuss and bug 658768.
Well, let's do that. 

1. Redirect to en-US unless we have them in settings.AAQ_LOCALES
2. Remove language switcher 

Instead of 2, we could also add a message that is only shown when your locale is not in settings.AAQ_LOCALES and that tells you to write in English only. But I'm pretty sure that would be just ignored.
Flags: needinfo?(a.topal)
Priority: -- → P3
Whiteboard: u=user c=aaq p= s=2013.16
Target Milestone: --- → 2013Q3
(Reporter)

Comment 11

5 years ago
Marking bug 885092 as dependent to prevent from being switched to the en-US locale when clicking a question in search results.
Depends on: 885092
(Reporter)

Updated

5 years ago
Depends on: 899071
This depends on a couple of open bugs, so I am moving it to the backlog for now.
Whiteboard: u=user c=aaq p= s=2013.16 → u=user c=aaq p= s=2013.backlog
Unblocking, putting into current sprint as P1.

I just noticed there are questions being posted:
https://support.mozilla.org/es/questions/feed
https://support.mozilla.org/fr/questions/feed

Nobody replies, because there is no way to get to them as a contributor without using those brand new RSS feeds per locale.

What should we be doing?

For now we can just save the questions with locale='en-US' if the locale being used isn't in AAQ_LANGUAGES. That would prevent questions being sent to a place nobody can find them at.
No longer depends on: 885092
Flags: needinfo?(mana)
Flags: needinfo?(a.topal)
Priority: P3 → P1
Whiteboard: u=user c=aaq p= s=2013.backlog → u=user c=aaq p=1 s=2013.19
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #13)
> What should we be doing?

We can redirect to 'en-US' in the AAQ view `if request.locale not in settings.AAQ_LANGUAGES`.
We should probably robots=>noindex all of the AAQ pages. That way google doesn't dump you into the middle of the flow in whatever locale.
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #14)
> (In reply to Ricky Rosario [:rrosario, :r1cky] from comment #13)
> > What should we be doing?
> 
> We can redirect to 'en-US' in the AAQ view `if request.locale not in
> settings.AAQ_LANGUAGES`.

Yeah, that we the decision earlier. Let's go ahead with that. I also like your noindex idea.
Flags: needinfo?(a.topal)
Also, it seems like some of those questions do actually have answers. No idea how people are seeing them though. Luckily it seems like there are just a few of them each month.
(Assignee)

Comment 18

5 years ago
Created attachment 809370 [details]
shot.png

PR: https://github.com/mozilla/kitsune/pull/1647

I have attached a screenshot.
(Assignee)

Updated

5 years ago
Assignee: nobody → mcooper
(Assignee)

Comment 20

5 years ago
I just pushed this to prod.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
no longer need any info.
Flags: needinfo?(mana)
You need to log in before you can comment on or make changes to this bug.