Closed ScottDowne closed 7 years ago
Thumbs up from l10n on the static website, see my detailed reply below regarding Bablic
Are there some hidden costs if we end up making changes to the copy in the NB site, via Bablic?
Quite a lot, actually. Several teams made it clear that they wouldn’t provide translations with a Bablic-based website, because of the terrible experience it was on the l10n side. First hidden cost is money, if we have to pay for all the translations. It can become quite costly if we forget some strings (and by experience, it’s very likely we do), and have to send multiple requests to the agency, paying for minimal charges each time.
Even though we get translations like for the previous campaign, we won’t have all of them at the same time, meaning that we would constantly have to paste them into Bablic. We would also have to monitor translation updates and uplift changes to Bablic, and make sure to publish them all. Also we can’t have multiple people working at the same time on Bablic, since it randomly causes data loss.
Every time the template changes, we lose translations and have to paste them again, with all the risks of doing it wrong. And the risk of displaying English content in localized pages.
We won’t be able to open the project to tier 2 EU locales, because of the above, while a .properties-based project in Pontoon would allow us to do it at no cost (so, potentially more impactful campaign at no additional cost)
If I can be of any help to build a static website, I’ll happily help. But relying on Bablic will be extremely difficult, with unknown outcomes, and it’s almost impossible to involve the community with such setup without putting our relationship at risk.
Theo had a concern that we used a new repo for this, vs adding pages to an existing repo. The issue with adding it to an existing repo is "Pontoon can’t filter files per locale on a given repo" so we would end up enabling the new strings on way too many locales, causing unneeded translations. I think we're fine here, given we want it on a new repo. If we need to solve this though, it feels solvable.
Got confirmation by Mathjazz that we would need a diferent repo, or a different branch at the very least (but I don’t think a new branch would make things better in our case). One possible workaround is storing the translations in a new repo, while adding the code in the current one (in case code has to be added here for some reason).
Timeline note: it seems comps will be worked on next week. My understanding is we can start localization after that, meaning the week of Feb 27. Does that work for you, @theochevalier?
@hannahkane TL;DR, if we’re doing a static site, yes.
Usually, we have to wait for the initial template to be coded before starting localization, but since we’re in a rush, Advocacy has special needs, and we have a well established process with .properties, I expect to be able to extract most strings from the final copy and the comps to build the localization file and start exposing it before the actual template is coded. I will share the comps with localizers so they can have context while translating. This way, we can start translating the bulk of strings earlier, and I expect the number of strings to retranslate after the coding is done to be low. Factors of re-translation can be links, markup or attributes in strings, but if we’re using variables for URLs in strings, risk should be low. ← @ScottDowne Once template coding is ongoing, I will work with Scott to extract the last strings we’re missing (things like error messages, or links that have been forgotten) and have them localized before the QA starts. Hopefully, this should be a few strings.
So what’s needed to start localization are comps and the final copy.
(actually learned what a comp is 👌)
Hi @TheoChevalier @hannahkane @lovegushwa @ScottDowne, here are the comps for the copyright v3 site. I have versions for desktop, tablet landscape, tablet portrait and mobile portrait. @TheoChevalier I would hold off on the footer strings for now as we're not sure which exact links we want. @hannahkane Could we confirm which footer links are needed for this page? Thank you both!
Thanks, @beccaklam! Added a ticket for footer links here: #723
Thanks, @beccaklam! @ScottDowne @cadecairos looks like we will need the new repo sooner than expected, should I go ahead and create a "copyright" repo to store the strings and expose them in Pontoon?
@ScottDowne implementation question, do you think you’ll need markup to style the first letter in blue, or using ::first-letter pseudo element will be enough?
@TheoChevalier Yeah, the first letter bit is mostly styled with :first-letter
However, there is a trick to make sure it's always going to line up with x number of line heights. And if things change in the font font size, the letter grows or shrinks. The example is deep in here: https://vimeo.com/180144290 we're trying it out.
And yes, we can setup a repo with locales/en-US/something.properties
(just like donate)
Project enabled in Pontoon https://pontoon.mozilla.org/projects/copyright-campaign/
@TheoChevalier Sorry to do this but we need to make some changes to some strings for localization. According to the new brand rules we are trying to stay away from all caps for navigation and headers and use sentence case instead. Therefore: 1) We need to change 'Copyright Campaign', 'More Resources', 'Get Involved' in the nav to sentence case. 2) We need to change the header for the form 'Ready to take action?' also to sentence case. CC: @lovegushwa @ScottDowne @hannahkane
Thanks, strings updated in https://github.com/mozilla/copyright/commit/6376b24c4223eac3e81567df29938fe07502fd30
I think the only possible thing left, that we can do here is add in a drop down for changing the language.
@TheoChevalier - is there a separate QA process for localization, or would you consider that completed?
@hannahkane Spelling errors and typos are covered by the community (each team has its own process), they will also report other kind of l10n related issues as they see them. So that should be covered, but nothing prevents us from checking layout issues/unlocalized strings too (I will check anyway)
@TheoChevalier - sounds good. Thanks for explaining the process to me!
@TheoChevalier - okay to close this ticket, or do you want to keep open until the language chooser component is done?
let’s close
Do we understand the flow for doing this in on a static site.
From my understanding, this would work pretty much like donate/advocacy. This are the steps I have a lot of experience in and has be tested under a lot of locales and traffic. Can also roll out this pretty quickly. I have a template for this that we may or may not use.
It's done with a
.properties
file living in github. Pontoon is setup to consume this, and make change to that repo. We would get in context translations. Then swap in the strings using pug or react-intl.Theo had a concern that we used a new repo for this, vs adding pages to an existing repo. The issue with adding it to an existing repo is "Pontoon can’t filter files par locale on a given repo" so we would end up enabling the new strings on way too many locales, causing unneeded translations. I think we're fine here, given we want it on a new repo. If we need to solve this though, it feels solvable.
Related: https://github.com/MozillaFoundation/Advocacy/issues/715 If we end up not doing a static site, and end up making changes to the copy in the NB site, via Bablic, are there hidden costs?
CC: @TheoChevalier