Closed Bug 909963 Opened 12 years ago Closed 10 years ago

L10N for homepage redesign

Categories

(www.mozilla.org :: L10N, defect)

Product:
www.mozilla.org
Component:
L10N
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jbertsch, Unassigned)

References

Details

Attachments

(1 file)

Mozilla_Homepage_Final-3.png
831.41 KB, image/png
Details
Hello Team L10N! We are currently working on a refresh for the Mozilla.org homepage and hope to have final, encoded text strings for your team by Thursday, September 12. I'll set up a time for all of us to meet the week of Sept 9. Thanks, Jen
OS: Mac OS X → All
Hardware: x86 → All
Hi Flod: I'd like to target the following as P1s for the homepage refresh since they already have local news blogs and include our 2 Fx OS locales: German Italian Polish Spanish French Thx, Jen
Hi Flod and Peiying - You can see the proposed design in the attached file.
(In reply to Jennifer Bertsch [:jbertsch] from comment #3) > Created attachment 796974 [details] > Mozilla_Homepage_Final-3.png I love the design, be ready for a way longer first message and, I fear, to lose some symmetry in the tile labels (sometimes I wish we had the same conciseness of English). (In reply to Jennifer Bertsch [:jbertsch] from comment #1) > German > Italian > Polish > Spanish > French My only concern about this list is Polish. Reaction times from their part have been quite slow in the last months, I think we need to talk with the team and understand if they have resources to manage it properly. At the moment I wouldn't consider it as a P1, but I'd like to hear Pascal's thoughts on this. Another thing we have to think about is how to answer other locales willing to localize the home (already received one request yesterday). We probably need two different "lanes", one for bigger locales able to react quickly in order not to slow down the entire development, another one for smaller locales (more static content/design).
Hi Flod- Other locales that would like to localize the new homepage are very welcome AND encouraged to do so, based on bandwidth availability within your team. I'd love to get it localized across as many locales as possible as quickly as possible :) As for Polish, I'm happy to take direction from your team and the community regarding prioritization. I think we are able to role out the locales one by one as they are complete. Thx, Jen
The code is available at https://github.com/mozilla/bedrock/tree/bug-904696-homepage-redesign The specific template is https://github.com/mozilla/bedrock/blob/bug-904696-homepage-redesign/bedrock/mozorg/templates/mozorg/home-b1.html The strings are all final but do let me know if anything needs tweaking. I'll have the page available on demo3 by the end of the day, but the url will be https://www-demo3.allizom.org/en-US/?v=1 (that's still the old page right now, until I push the code).
Also, see bug 910419 for links and headlines for the news block, for those locales. For locales without localized news links, we should *not* translate that block and would show the en-US news by default, even when the rest of the page is localized. We're working on a better strategy for the near future but for now that's the best compromise.
At least locally (our dev servers are down), the branch doesn't render localizations for home.html and home-b1.html while the master branch shows home.html as localized. I notice that in views.py all the functions return something along those lines: return l10n_utils.render(request, template, data) While on the branch the class HomeTestView returns: return [template] so maybe it needs to call l10n_utils.render at some point, I don't know.
{# L10n: The Mozilla wordmark appears inline as part of this headline, so it reads as "We are Mozilla." The alt text should not be translated. #} {{ _('We are <img src="%(img)s" alt="Mozilla" height="70" width="258">.') | format(img=media('img/home/mozilla-wordmark-red.png')) }} Can we simplify this? Currently it means that if we change the dimension of the image for example, it will invalidate all translations. Actually, the current home page string has different values and we couldn't reuse the French translation for example. Also the l10n comment actually says 'in that string given for localization there is content not to localize', in that case I think we should just not expose it to localizers with something like: {# L10n: The Mozilla wordmark is inserted with an <img> tag as part of this headline, so it reads as "We are Mozilla." #} {{ _('We are %(mozilla_wordmark)s.') | format(mozilla_wordmark='<img src="'|safe+media('img/home/mozilla-wordmark-red.png')+'" alt="Mozilla" height="70" width="258">'|safe) }}
I've updated the branch to address comment 9 and comment 10, cc'ing pmac for thoughts on comment 8.
Yeah. Comment 8 is my bad. Fixing now.
(In reply to Francesco Lodolo [:flod] from comment #13) > Also "See all news" seems not localizable > https://github.com/mozilla/bedrock/blob/bug-904696-homepage-redesign/bedrock/ > mozorg/templates/mozorg/home-b1.html#L149 It's within the l10n home_news block, but perhaps that's not the best way to do it. The link's href needs to change for each locale as well as the text. Would I just wrap the URL as a string as well? Like so: <a href="{{ _('https://blog.mozilla.org') }}">{{ _('See all news') }}</a> Would that be preferable?
Also, there's been a very minor string change today. We've removed the . from the end of the "We are Mozilla" headline. Sorry about that.
(In reply to Craig Cook (:craigcook) from comment #14) > <a href="{{ _('https://blog.mozilla.org') }}">{{ _('See all news') }}</a> > > Would that be preferable? I am not sure if it is supposed to be https://blog.mozilla.org/press/ or https://blog.mozilla.org/press/ here, but we now have an helper function to insert the right press blog automatically: {{ press_blog_url() }}
Will this page remain in the home-b1.html template or will it replace the code in home.html? If the latter, can we add {% add_lang_files "mozorg/home" %} in the template so as that it picks up strings from home.lang and not a new home-b1.lang? I'd like to avoid renaming files later.
L10n note in the template: "If your locale doesn't have approved, localized news items to display here, don't translate this block. We'll display the US English for now until we have a better solution. " This is likely to generate frustration for most of our locales and having mixed English and localized content is also not great. I would prefer that we display this block only for locales for which we have a press blog for now and I don't think we need to put that in the translatable files, we should just keep a list of titles/urls per locale in the template or in an helper function IMO, this is content created by our PR team, not by our localizers, the translation already exists and there is nothing to localize, so basically that would be asking localizers to copy/paste text and urls provided by the PR team on a regular basis, not a great use of their time IMO :).
(In reply to Pascal Chevrel:pascalc from comment #18) > Will this page remain in the home-b1.html template or will it replace the > code in home.html? If the latter, can we add {% add_lang_files "mozorg/home" > %} in the template so as that it picks up strings from home.lang and not a > new home-b1.lang? I'd like to avoid renaming files later. Yes, let's do that, because there will also be a home-b2.html and home-b3.html and so on as we test design variations. They'll all have the same text strings, just slightly rearranged. And the plan is that, if it performs well, one of these variations will indeed take over home.html.
(In reply to Pascal Chevrel:pascalc from comment #19) > This is likely to generate frustration for most of our locales and having > mixed English and localized content is also not great. I would prefer that > we display this block only for locales for which we have a press blog for > now Unfortunately we don't have any other content to show in that space for locales that don't have localized news. We're trying to come up with some kind of universal placeholder to show when news isn't available but didn't want to block on it for the first release. Mixed content is bad, but so is empty space. I don't know what the better compromise will be, but we'll have it soon. > and I don't think we need to put that in the translatable files, we > should just keep a list of titles/urls per locale in the template or in an > helper function IMO, this is content created by our PR team, not by our > localizers, the translation already exists and there is nothing to localize, > so basically that would be asking localizers to copy/paste text and urls > provided by the PR team on a regular basis, not a great use of their time > IMO :). Agreed, that was bad planning on my part. We eventually want to have some mechanism in place for local PR to update news automatically, but you're right, that shouldn't be the job of localizers. I'll remove that l10n block.
(In reply to Craig Cook (:craigcook) from comment #21) > (In reply to Pascal Chevrel:pascalc from comment #19) > > > This is likely to generate frustration for most of our locales and having > > mixed English and localized content is also not great. I would prefer that > > we display this block only for locales for which we have a press blog for > > now > > Unfortunately we don't have any other content to show in that space for > locales that don't have localized news. We're trying to come up with some > kind of universal placeholder to show when news isn't available but didn't > want to block on it for the first release. Mixed content is bad, but so is > empty space. I don't know what the better compromise will be, but we'll have > it soon. Mixed content is bad, just imagine that on the en-US page you have the choice between having a block of news in Spanish or German, I think end users would prefer not to see text in a foreign language. We can work on putting per locale selected content later, but for a 1st iteration, I would prefer that for the home page we start with a clean page all translated, not partially.
Here's our course of action for "in the news" 1. locales with a pr blog: news items managed by Mozilla (listed in comment #1 above) 2. locales without a pr blog: link to /contribute if we it localized for that locale in place of the "in the news" section (listed with a green square in the "activated" column here http://l10n.mozilla-community.org/~pascalc/langchecker/?locale=all&website=0&file=mozorg/contribute.lang) 2a. We'll use the snippet's text "You don’t have to know how to code to get involved with Mozilla. Learn more about our volunteer opportunities." for this. Are the next steps: ->Craig to code the string into the template? ->Pascal/L10N team to update the .lang files with the existing translations? 3. locales without a pr blog and without a contribute page: offer 1-2 other messages depending on the local needs. For example, we could ask for l10n volunteers for a locale or we could ask people to become Fx OS mobilizers 3a. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=918594 for the localization of the "become an Fx OS mobilizer message". Craig - the final text and links are there. 3b. Per Chelsea's request, we'll use the mobilizer message for es, hu, and pt-BR because that is where there is the most need (even though it overrides the logic outlined above). 3c. Pascal - do you have "join the L10N team" language for Matej to review and Craig to code? Should I file a separate bug? Thanks all for helping us work this out!
(In reply to Jennifer Bertsch [:jbertsch] from comment #23) > 3c. Pascal - do you have "join the L10N team" language for Matej to review > and Craig to code? Should I file a separate bug? A separate bug would be probably easier to follow. I think we need also to decide where to point that link (l10n.mozilla.org or somewhere more specific?).
(In reply to Francesco Lodolo [:flod] from comment #24) > (In reply to Jennifer Bertsch [:jbertsch] from comment #23) > > 3c. Pascal - do you have "join the L10N team" language for Matej to review > > and Craig to code? Should I file a separate bug? > > A separate bug would be probably easier to follow. I think we need also to > decide where to point that link (l10n.mozilla.org or somewhere more > specific?). Hi Flod- I'll file a new bug. I'm find with pointing to l10n.mozilla.org if that is what your team chooses. Thanks!
The sentence "Doing good is part of our code." ends with a period on the new version and not on the current version of the home page, is that wanted?
(In reply to Pascal Chevrel:pascalc from comment #26) > The sentence "Doing good is part of our code." ends with a period on the new > version and not on the current version of the home page, is that wanted? No period
(In reply to Jennifer Bertsch [:jbertsch] from comment #27) > (In reply to Pascal Chevrel:pascalc from comment #26) > > The sentence "Doing good is part of our code." ends with a period on the new > > version and not on the current version of the home page, is that wanted? > > No period Updated the string in https://github.com/mozilla/bedrock/commit/350034fc
Depends on: 918974
The page was pushed for: af an bg ca cs de el eo es-AR es-CL es-ES et eu fr fy-NL is it ko nl rm sk sl sq sv-SE uk ga-IE he id
locales added over the last week: ast br hr ja lt mk pl zh-CN
locales added over the last week: ar da es-MX he hu hy-AM ru
locales added over the last week: fi gd pt-BR tr Current list of locales on prod: af an ar ast bg br ca cs da de el eo es-AR es-CL es-ES es-MX et eu fi fr fy-NL ga-IE gd he hr hu hy-AM id is it ko lt mk nl pl pt-BR rm ru sk sl sq sv-SE tr uk zh-CN
Closing old bugs.
Status: NEW → RESOLVED
Closed: 10 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: