Closed Bug 1115626 Opened 10 years ago Closed 9 years ago

Stop redirecting mozilla.org/zh-TW/firefox to Mozilla Taiwan website

Categories

(www.mozilla.org :: Pages & Content, defect)

Product:
www.mozilla.org
Component:
Pages & Content
Version:
Production
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: petercpg, Assigned: petercpg)

References

(Blocks 1 open bug)

Details

(Whiteboard: [kb=1560820])

Attachments

(1 file)

pull request to remove redirection
(deleted), text/x-github-pull-request
petercpg
: review?
Details 
In Bug 764261 we redirected all traffics of mozilla.org/zh-TW to mozilla.com.tw, by then Bedrock is not very good for i18n contents. 

For more than 2 years, Bedrock evolved a lot, but with the redirection, many in-product page links were broken, not updated information staying for a long time, apparently our full-time employees did not maintain the l10n of these pages well. It also made the config files messy and harming local users and l10n community.

So far I have filed many bugs to revert the redirection of many pages. As the once-disputed Firefox "Taiwan Version" is discontinued, and we're going to release new Hello page with Firefox 35, I think it's time to revert the change at /firefox/ level.

Please note that I'm *not* asking to take down all contents published by MoCo-TP or avoid cooperation, but I believe it's much better now to go back to our One Mozilla theme. Thanks.
+Michael Hung for his thoughts.
One more thought: I discovered recently that we have specific redirect rules for dev, I wonder if it makes sense to remove the redirect completely for https://www-dev.allizom.org/zh-TW
Blocks: mozorg-redirects
(In reply to Peter Pin-Guang Chen [:petercpg] (MozTW.org) from comment #0)
> In Bug 764261 we redirected all traffics of mozilla.org/zh-TW to
> mozilla.com.tw, by then Bedrock is not very good for i18n contents. 
> 
> For more than 2 years, Bedrock evolved a lot, but with the redirection, many
> in-product page links were broken, not updated information staying for a
> long time, apparently our full-time employees did not maintain the l10n of
> these pages well. It also made the config files messy and harming local
> users and l10n community.
> 
> So far I have filed many bugs to revert the redirection of many pages. As
> the once-disputed Firefox "Taiwan Version" is discontinued, and we're going
> to release new Hello page with Firefox 35, I think it's time to revert the
> change at /firefox/ level.
> 
> Please note that I'm *not* asking to take down all contents published by
> MoCo-TP or avoid cooperation, but I believe it's much better now to go back
> to our One Mozilla theme. Thanks.

Hi Peter,


Sorry for the late reply.
Although "Taiwan Version Firefox" discontinued,
we have local news, blogs, and campaigns on mozilla.com.tw.
So we decided to keep the redirection settings this way.

We would be actively merging new pages and content under /firefox/,
so if any broken redirection/content occurs, 
please do fire me a bug, or include me in bug comments.
I could also help adding exception rules for in-product pages to keep them on www.mozilla.org


Thanks!
(In reply to elin from comment #4)
> We would be actively merging new pages and content under /firefox/,
> so if any broken redirection/content occurs, 
> please do fire me a bug, or include me in bug comments.

I think you're missing one important issue: a lot of pages these days rely on the Mozilla.UITour feature, which lets pages interact directly with Firefox UI. It's the case of firefox/new, firefox/hello, what's new/first run pages, and probably more in the future. 

That works only with mozilla.org, the only domain whitelisted, you can't port that to a different domain.
(In reply to Francesco Lodolo [:flod] from comment #5)
> (In reply to elin from comment #4)
> > We would be actively merging new pages and content under /firefox/,
> > so if any broken redirection/content occurs, 
> > please do fire me a bug, or include me in bug comments.
> 
> I think you're missing one important issue: a lot of pages these days rely
> on the Mozilla.UITour feature, which lets pages interact directly with
> Firefox UI. It's the case of firefox/new, firefox/hello, what's new/first
> run pages, and probably more in the future. 
> 
> That works only with mozilla.org, the only domain whitelisted, you can't
> port that to a different domain.

Hi, 

We were aware of these problems,
previously when we have our localized version of Firefox,
we add mozilla.com.tw to the whitelist.

But now it discontinued,
so the solution we proposed is to add exception rules for these pages,
currently firstrun/whatsnew/tour/hello is in the exception rules,
which means it won't redirect to mozilla.com.tw.

We'll be watching new in-product pages like these,
and help create PR to add exception rules if there will be more.

for those pages without interaction with Firefox UI,
we will be merging them into mozilla.com.tw
I don't see the benefit in double working to remake those contents again locally.

If the target is to promoting local campaign, blog, news,
the more logical way is just redirect the root (mozilla.org/zh-TW),
and revert everything else to save the resource for making better local content.
Hi Irvin,

Our concern is mainly about SEO,
we'll have more search traffic when we have higher search rankings,
page redirection and our local links would help transfer SEO ranking and traffic.

The problem I can think of now is 
that contents on mozilla.com.tw is not easily interoperable for community,
maybe we could discuss about this in another bug.
to elin from comment #8)
> Hi Irvin,
> 
> Our concern is mainly about SEO,
> we'll have more search traffic when we have higher search rankings,
> page redirection and our local links would help transfer SEO ranking and
> traffic.

Which local content "page" do we need to raise the SEO with such complicated mechanism and take the risk to confusing the user? 

Those content which is available in mozilla.org/zh-TW/* already had good enough page rank (If not so you don't want to 'redirect' them), duplicate another local one don't help at all.

And if the targeting content are those local news and blog posts (those page are the most significant specific local content in mozilla.com.tw ) then redirecting the root would be enough. And we should figure out how to make these news/articles interoperating into bedrock / mozilla.org (perhaps blog.mozilla.org, planet.mozilla.org or somewhere in Tabzilla or even in homepage), then those content will even get far better SEO result benefit from mozilla.org's long existing history.


> The problem I can think of now is 
> that contents on mozilla.com.tw is not easily interoperable for community,
> maybe we could discuss about this in another bug.
I agree we can discuss this further on bugzilla or locally, 
but that's another issue which is not raising in this bug and nor me or Peter's concerning here.

Our main concern is that the whole "redirect" mechanism causing a lot of broken links and confusing a lot of users for so long period. We cannot always chasing after the broken links as Bedrock and mozilla.org continuance to evolving. Broken links and contents you have to REMAKE are not gonna to stop appearing in this workaround way. 

That's the waste of time of you and me and Mozilla's precious human resources and all users' confidence to Mozilla who had fallen into the hole of broken redirect links!
(In reply to elin from comment #4)
> Although "Taiwan Version Firefox" discontinued,
> we have local news, blogs, and campaigns on mozilla.com.tw.
> So we decided to keep the redirection settings this way.

I second Irvin's idea from comment #7. The scope of this bug is only about mozilla.org/zh-TW/firefox, you will still have mozilla.org/zh-TW redirected, and you already have your blog.mozilla.com.tw controlled.

Looking at contents on mozilla.com.tw since redirection, probably the redirection rules should be whitelists (redirect only needed pages to mozilla.com.tw, as well as other paths needed in campaigns) instead of blacklists (keep exceptions on mozilla.org, otherwise redirected to mozilla.com.tw) to be more logical and saving everybody's time.

> We would be actively merging new pages and content under /firefox/,
> so if any broken redirection/content occurs, 
> please do fire me a bug, or include me in bug comments.
> I could also help adding exception rules for in-product pages to keep them
> on www.mozilla.org

I do also file bugs here to add expection on redirect rules. Since MoCo-TPE made the redirection, I belive you (MoCo-TPE) need an auto-pulling mechanism to sync the pages, instead of letting it broke then fix up passively. Besides auto-updating, another problem here is mozilla.com.tw does not have an open repository so any non-MoCo people can work on.
(In reply to elin from comment #8)
> Our concern is mainly about SEO,
> we'll have more search traffic when we have higher search rankings,
> page redirection and our local links would help transfer SEO ranking and
> traffic.

No offense, but I will be surprised that Mozilla is caring about traffics and search engine ranking in this way. What do you advertise on mozilla.com.tw, and why mozilla.org don't help?
(In reply to Peter Pin-Guang Chen [:petercpg] (MozTW.org) from comment #10)
> I do also file bugs here to add expection on redirect rules. Since MoCo-TPE
> made the redirection, I belive you (MoCo-TPE) need an auto-pulling mechanism
> to sync the pages, instead of letting it broke then fix up passively.
> Besides auto-updating, another problem here is mozilla.com.tw does not have
> an open repository so any non-MoCo people can work on.

Hi,


Here's the github:
https://github.com/elin-moco/bedrock/
I would like to discuss more about how we could cowork on this.

I've also been (and will be) trying to optimize the workflow to sync new pages/contents in time.

BTW,
would you guys be in the community space this evening?
I would come by and stay for a while.
(In reply to elin from comment #12)
> (In reply to Peter Pin-Guang Chen [:petercpg] (MozTW.org) from comment #10)
> > I do also file bugs here to add expection on redirect rules. Since MoCo-TPE
> > made the redirection, I belive you (MoCo-TPE) need an auto-pulling mechanism
> > to sync the pages, instead of letting it broke then fix up passively.
> > Besides auto-updating, another problem here is mozilla.com.tw does not have
> > an open repository so any non-MoCo people can work on.
> 
> Hi,
> 
> 
> Here's the github:
> https://github.com/elin-moco/bedrock/
> I would like to discuss more about how we could cowork on this.
> 
> I've also been (and will be) trying to optimize the workflow to sync new
> pages/contents in time.
> 
> BTW,
> would you guys be in the community space this evening?
> I would come by and stay for a while.

It's nice to hear that finally there's an open repository. 

I'm not going to Lab tonight and next week, while Irvin might be there (usually late). For open discussion, please email to moztw-general@googlegroups.com. Thanks.
Just adding some more thoughts for discussion:

I can totally understand wanting to keep pages like the mozilla.org/zh-TW homepage redirected for local news, press and SEO etc. It does make sense in this regard +1.

With regard to /zh-TW/firefox/ however, I'm not sure if it makes as much sense to carry on duplicating development efforts here with another repository, since many of these mozilla.org pages are already translated for zh-TW on bedrock.

There are also other factors to consider: 

- Many of these pages now also use UITour API as mentioned previously, which only works on whitelisted domains. But even if we added mozilla.com.tw to the whitelist, it is important to keep these pages up to date as the browser side of the API changes. Not having enough eyes on this could risk breakage if pages and libraries we're not kept up to date.

- Pages such as /firefox/os and /firefox/os/devices also update frequently, and in the past we have noticed the /zh-TW/ pages being out of date with recent launches etc. This has caused some confusion in the past, and out-of-date content would also likely hurt SEO. We have since added exceptions for these pages.

- If there is /zh-TW/ specific content you would like to add to pages on bedrock, we do have the ability to show some locale-specific content in the templates. Adding in different pieces of text/links for example, probably wouldn't require a separate fork of the site in many cases.

- Finally, adding in more exception rules probably doesn't make much sense long term, considering that we already have exceptions for a lot of current pages: https://github.com/mozilla/bedrock/blob/master/etc/httpd/global.conf#L32. It seems like we could probably save work on both sides here, as well as simplify our redirect rules if we used a single exception for /zh-TW/firefox/
(In reply to Alex Gibson [:agibson] from comment #14)
> Just adding some more thoughts for discussion:
> 
> I can totally understand wanting to keep pages like the mozilla.org/zh-TW
> homepage redirected for local news, press and SEO etc. It does make sense in
> this regard +1.
> 
> With regard to /zh-TW/firefox/ however, I'm not sure if it makes as much
> sense to carry on duplicating development efforts here with another
> repository, since many of these mozilla.org pages are already translated for
> zh-TW on bedrock.
> 
> There are also other factors to consider: 
> 
> - Many of these pages now also use UITour API as mentioned previously, which
> only works on whitelisted domains. But even if we added mozilla.com.tw to
> the whitelist, it is important to keep these pages up to date as the browser
> side of the API changes. Not having enough eyes on this could risk breakage
> if pages and libraries we're not kept up to date.
> 
> - Pages such as /firefox/os and /firefox/os/devices also update frequently,
> and in the past we have noticed the /zh-TW/ pages being out of date with
> recent launches etc. This has caused some confusion in the past, and
> out-of-date content would also likely hurt SEO. We have since added
> exceptions for these pages.
> 
> - If there is /zh-TW/ specific content you would like to add to pages on
> bedrock, we do have the ability to show some locale-specific content in the
> templates. Adding in different pieces of text/links for example, probably
> wouldn't require a separate fork of the site in many cases.
> 
> - Finally, adding in more exception rules probably doesn't make much sense
> long term, considering that we already have exceptions for a lot of current
> pages:
> https://github.com/mozilla/bedrock/blob/master/etc/httpd/global.conf#L32. It
> seems like we could probably save work on both sides here, as well as
> simplify our redirect rules if we used a single exception for /zh-TW/firefox/

Thanks for commenting on this discussion, Alex!

Elin- Any thoughts?
Flags: needinfo?(elin)
There's another consideration,
we didn't just copy everything and host it on another server,
we maintain consistency of wording across all pages in mozilla.com.tw,
and than we change links in those pages to whatever localized content we have,
those contents might be in mozilla.com.tw, blog.mozilla.com.tw, tech.mozilla.com.tw, developer.mozilla.org/zh-TW/...etc.
It's simpler to link to SUMO if we link to locale-neutral URLs on SUMO,
because the URL structures are the same across different languages.

but it's not the case for some documents on MDN, or for blog.mozilla.org,
so when users clicked those links on mozilla.org, 
they probably won't be able to see localized contents directly.

Here are some examples:

Firefox OS
http://mozilla.com.tw/firefox/os/
At the bottom there's an MDN link:
https://developer.mozilla.org/en-US/Marketplace/Publishing/Submit/Submitting_an_app
we change the link to localized version:
https://developer.mozilla.org/zh-TW/docs/%E6%87%89%E7%94%A8%E7%A8%8B%E5%BC%8F-840092-dup/Publishing/Submitting_an_app
And because we have dedicated devs working on Firefox OS here in Taipei Office,
we are also maintaining tech.mozilla.com.tw for articles about latest Firefox OS development.
and these are something we hope Chinese users/devs can see when they come to mozilla website.


Firefox Desktop - Trust
http://mozilla.com.tw/firefox/desktop/trust/
Under the badge is the link to the privacy day blog post:
https://blog.mozilla.org/blog/2015/01/27/get-smart-on-international-data-privacy-day/
And we change the link to our localized blog post:
http://blog.mozilla.com.tw/posts/7052/get-smart-on-dpd

and cases like these would still appear when new pages come out.

Any suggestions how we can deal with these 
if we want pages on mozilla.org/zh-TW/ link to localized content directly?
I assume that adding {% if request.locale == 'zh-TW' %} in templates won't be an option...
Flags: needinfo?(elin)
(In reply to elin from comment #16)
> At the bottom there's an MDN link:
> https://developer.mozilla.org/en-US/Marketplace/Publishing/Submit/
> Submitting_an_app
> we change the link to localized version:
> https://developer.mozilla.org/zh-TW/docs/
> %E6%87%89%E7%94%A8%E7%A8%8B%E5%BC%8F-840092-dup/Publishing/Submitting_an_app

IMO that's an issue that needs to be fixed on MDN (i.e. translation disconnected from the original document), locale agnostic links are supposed to work.
Try opening https://developer.mozilla.org/Firefox_OS/Using_the_App_Manager for example
(In reply to elin from comment #16)
> There's another consideration,
> we didn't just copy everything and host it on another server,
> we maintain consistency of wording across all pages in mozilla.com.tw,
> and than we change links in those pages to whatever localized content we
> have,
> those contents might be in mozilla.com.tw, blog.mozilla.com.tw,
> tech.mozilla.com.tw, developer.mozilla.org/zh-TW/...etc.
> It's simpler to link to SUMO if we link to locale-neutral URLs on SUMO,
> because the URL structures are the same across different languages.

This should be a bug of MDN or any other products. 

SUMO has such problems as well so I required localizers to use original slug when creating localized article, but the system doesn't merely depend on the slug to keep the connection between original article and localizations. 

> 
> but it's not the case for some documents on MDN, or for blog.mozilla.org,
> so when users clicked those links on mozilla.org, 
> they probably won't be able to see localized contents directly.
> 
> Here are some examples:
> 
> Firefox OS
> http://mozilla.com.tw/firefox/os/
> At the bottom there's an MDN link:
> https://developer.mozilla.org/en-US/Marketplace/Publishing/Submit/
> Submitting_an_app
> we change the link to localized version:
> https://developer.mozilla.org/zh-TW/docs/
> %E6%87%89%E7%94%A8%E7%A8%8B%E5%BC%8F-840092-dup/Publishing/Submitting_an_app
> And because we have dedicated devs working on Firefox OS here in Taipei
> Office,
> we are also maintaining tech.mozilla.com.tw for articles about latest
> Firefox OS development.
> and these are something we hope Chinese users/devs can see when they come to
> mozilla website.

I don't know why this happened but this MDN article should be moved to https://developer.mozilla.org/zh-TW/Marketplace/Publishing/Submit/Submitting_an_app for the locale auto-detection and correct fallback. 

Besides that, /en-US/Marketplace/Publishing/Submit/Submitting_an_app and /zh-TW/docs/應用程式-840092-dup/Publishing/Submitting_an_app look two different articles IMO, the path of zh-TW article /docs/應用程式-840092-dup/ looks weird, too.
Agree these are more MDN/SUMO related issues that should probably be resolved there, rather than on mozilla.org.

Regardless, we could still probably work together to provide locale specific links on pages where they may be required. A current example of this is on the Nightly /firstrun page: https://github.com/mozilla/bedrock/blob/master/bedrock/firefox/templates/firefox/nightly_firstrun.html
(In reply to elin from comment #16)
> Any suggestions how we can deal with these 
> if we want pages on mozilla.org/zh-TW/ link to localized content directly?
> I assume that adding {% if request.locale == 'zh-TW' %} in templates won't
> be an option...

If the outside link has a locale negociation bug we can't fix, I don't see why we couldn't do it. Putting a few conditionnals in templates for your locale is a lot less webdev work than cloning the full site isn't it?
Do you still have any problem/issues preventing this bug from fixed, elin?
Flags: needinfo?(elin)
Just realized new MWC contents are coming, I think we should be safe enough to fix this bug to minimize page redirection problems as elin seems to have no echo.
Taking this bug.
Assignee: nobody → petercpg
Flags: needinfo?(elin)
Attached file pull request to remove redirection (deleted) — 
Removed /zh-TW/firefox redirection and cleared other RewriteConds created from old bugs.
Attachment #8585191 - Flags: review?
Whiteboard: [kb=1560820]
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/8a385bf2bf323756b399214e9a485ecbc577be7f
Bug 1115626, Remove zh-TW/firefox/ redir; old rule cleanup

https://github.com/mozilla/bedrock/commit/756b4d5c39bc1480d14e8cd92b1ee3b3ddde7994
Merge pull request #2876 from petercpg/bug-1115626-stop-redirecting-mozilla.org-zhtw-firefox-to-mocotw

Bug 1115626, Remove zh-TW/firefox/ redir; old rule cleanup
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: