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).
> 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?
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?
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.
(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.
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?
https://support.mozilla.org/users/auth links to /questions/new which will present the localized AAQ.
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.
Priority: -- → P3
Whiteboard: u=user c=aaq p= s=2013.16
Target Milestone: --- → 2013Q3
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
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
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.
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.
Created attachment 809370 [details] shot.png PR: https://github.com/mozilla/kitsune/pull/1647 I have attached a screenshot.
I just pushed this to prod.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
no longer need any info.
You need to log in before you can comment on or make changes to this bug.