Closed Bug 1189920 Opened 9 years ago Closed 9 years ago

Need a sumo page for Kidfox

Categories

(Firefox for Android Graveyard :: Profile Handling, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ally, Unassigned)

References

Details

will be included in the first run tiles
Flags: needinfo?(jsavage)
Blocks: 1125280
Hi Allison, I've set up a placeholder link for the upcoming SUMO article. Here's the slug: 

https://support.mozilla.org/1/mobile/%VERSION%/%OS%/%LOCALE%/kids   (just replace the version/OS/locale tuple)
Flags: needinfo?(jsavage)
Blocks: kidfox-v1
(In reply to Joni Savage from comment #1)
> Hi Allison, I've set up a placeholder link for the upcoming SUMO article.
> Here's the slug: 
> 
> https://support.mozilla.org/1/mobile/%VERSION%/%OS%/%LOCALE%/kids   (just
> replace the version/OS/locale tuple)

Does this mean Ill have to hardcode this link to english, or can I leave the locale part alone?
Flags: needinfo?(jsavage)
Can we have something along the lines of "https://support.mozilla.org/kb/how-does-insecure-content-affect-safety-android" ? I'm in java and won't have hte ability to format it.

How about "https://support.mozilla.org/kb/kids ?
Hi Allison, 

Let's check with Mike Cooper from SUMO Dev. Mike, if an article is linked from the UI, is there a downside to using the direct URL instead of using a redirect?

And if Allison were to use the redirect format, would she have to hardcode the locale part? https://support.mozilla.org/1/mobile/%VERSION%/%OS%/%LOCALE%/kids
Flags: needinfo?(jsavage) → needinfo?(mcooper)
The main reason for the redirect format is durability. It is a lot easier for us to keep those links working into the far future, and even chage what clients will get in the future based on a variety of factors.

The configuration we have for these redirects can ignore or include any of the component (mobile, version, os, locale, and slug). Additionally, we can choose to redirect to a locale-neutral page, so that our normal locale selection process can take hold. In desktop Firefox, the locale in /1/mobile/%VERSION%/%OS%/%LOCALE%/ url is whatever the current installation is using. However, we usually ignore that locale when redirecting to articles.

The redirect format gives us a lot more flexibility in the future. If Joni is ok making sure that whatever slug she chooses will remain valid for the lifetime of Firefox for Android, and we always want all clients to see the same article, we don't have to use the redirect form.

That being said, I find it hard to believe that you can't format a string based on the version of the product and locale of the user (I assume OS would be constant).
Flags: needinfo?(mcooper)
Thanks, mythmon.

Ally, if there's no workaround, we can make "https://support.mozilla.org/kb/kids" work. 

I'll put a note in the article for the community to make sure we keep the URL valid.
Flags: needinfo?(ally)
(In reply to Mike Cooper [:mythmon] from comment #5)

> Additionally, we can choose to redirect to a locale-neutral page, so that our normal locale selection process can take hold.

So then https://support.mozilla.org/1/mobile/kb/kids would be locale neutral?

> That being said, I find it hard to believe that you can't format a string
> based on the version of the product and locale of the user (I assume OS
> would be constant).

The strings are slurped out of a localized properties file.

The one for sumo tile on normal mobile is https://support.mozilla.org/en-US/products/mobile. How does that handle redirects? Can we do that identical thing here, something like https://support.mozilla.org/en-US/products/mobile/kids?



Since
Flags: needinfo?(ally)
Since teh region.properties file is localized, do we just force the localizers to supply the locale substitution in the strings?
Flags: needinfo?(margaret.leibovic)
> So then https://support.mozilla.org/1/mobile/kb/kids would be locale neutral?

No. You still need to fill in all the fields. "kb" isn't a field. All urls that start with /1/ are special redirect urls. We can just ignore any field in the redirect.

Anyways, it sounds like you don't care for the features that the redirect offers. You don't want to have customized redirects per locale or versions, you just want a link. Since our showfor system is pretty powerful, this should work out fine.

https://support.mozilla.org/en-US/products/mobile is just a normal link (unlike the redirect links that start with /1/) to our Firefox for Android product page. We can't do any smart handling of that. Worse yet, it is hard coded to always point to the English version of the site. A better version would be https://support.mozilla.org/products/mobile, which will let us redirect users to an appropriate locale.

https://support.mozilla.org/en-US/products/mobile/kids isn't a valid url on Sumo. I think what you want is https://support.mozilla.org/kb/kids, which will link to a specific KB article, which can't ever be moved or renamed. However, we *will* be able to do locale redirection to make sure the article is at least in the correct language (to the best of our localizers abilities).
(In reply to Mike Cooper [:mythmon] from comment #9)
> > So then https://support.mozilla.org/1/mobile/kb/kids would be locale neutral?
> 
> No. You still need to fill in all the fields. "kb" isn't a field. All urls
> that start with /1/ are special redirect urls. We can just ignore any field
> in the redirect.
> 
> Anyways, it sounds like you don't care for the features that the redirect
> offers. You don't want to have customized redirects per locale or versions,
> you just want a link. Since our showfor system is pretty powerful, this
> should work out fine.
> 
> https://support.mozilla.org/en-US/products/mobile is just a normal link
> (unlike the redirect links that start with /1/) to our Firefox for Android
> product page. We can't do any smart handling of that. Worse yet, it is hard
> coded to always point to the English version of the site. A better version
> would be https://support.mozilla.org/products/mobile, which will let us
> redirect users to an appropriate locale.
> 
> https://support.mozilla.org/en-US/products/mobile/kids isn't a valid url on
> Sumo. I think what you want is https://support.mozilla.org/kb/kids, which
> will link to a specific KB article, which can't ever be moved or renamed.
> However, we *will* be able to do locale redirection to make sure the article
> is at least in the correct language (to the best of our localizers
> abilities).

Yes, I think we should just go with https://support.mozilla.org/kb/kids.

Thanks for your help, Mike. As Ally mentioned previously, the reason this is so tricky is that we're using this in our suggested sites framework, which doesn't give us the normal capability for formatting URLs within the client code.

Ally, you can also needinfo or request feedback from flod in whatever patch you're writing to use this URL, since he should be aware of how localizers currently deal with our suggested sites.

I should also note that region.properties is a bit of a special locale file - I believe our l10n team is more involved in controlling changes to localized versions, since it contains important things like default search engine order. So it would be good to communicate with the l10n team about any new items you're adding to this file.

Also, if localizers don't need to translate this URL directly, we probably don't need to worry as much about string freeze (i.e. we could uplift this if we need to).
Flags: needinfo?(margaret.leibovic)
I've reached out to flod, and landed the tiles patch.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Just to close the loop here, and sorry for coming in so late, Joni, is there anything you need from us in regards to the title or content.

We could use some of the wording from Matej:https://bugzilla.mozilla.org/show_bug.cgi?id=1188528#c2
Flags: needinfo?(jsavage)
Hi Barbara, I think we have everything we need at this point. I'll use Matej's wording and the docs that Sam sent us and have a draft ready soon.
Flags: needinfo?(jsavage)
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.