-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VPN-6649 - Fix Malmö
translation
#9964
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like this fix, it feels very brittle and it fills me with concern over what exactly is allowed to be input as a valid string ID. I would prefer that we change the servers.Malmö
ID to just servers.Malmo
and rely on the translations to turn that into Malmö
as appropriate.
If it's just one city translation to deal with, it shouldn't be that hard to copy the files over in Pontoon as necessary. Or there more to it than just changing the string ID in the VPN app (eg: does the ID come from guardian or something?).
I agree that it's waaaay too brittle. The ID comes from the English name of the city. So we'd have to change the name of the city in the app to use Alternatively, we could strip special characters before sending it out to be translated, so the translation string is How does that sound? In my mind, it's a bit more generalizable (it should work for any future cities with a special character), though it would take work w/ the translations team. If this sounds like an okay approach to you, let me know and I'll close this PR in favor of a new one. |
I am in favor of changing the city ID to We probably also want to enforce some kind of lint to ensure that the IDs only contain ASCII characters or something to prevent this from happening again in the future. |
The city ID is a derivative of the English city name, which in turn comes directly from Mullvad. So we can't change the city ID to We already use a parsed city string ID of Potential steps forward, since we're both agreed this is hacky:
My inclination is #1 or #4 (if you have other ideas), but I'm genuinely open to any of these paths. |
Closing in favor of #10029 |
Description
Malmö is the only city with special characters in the name. Our build scripts should handle this fine - and we use
Servers.Malm
for the string ID. It builds perfectly on my machine, but was failing on TaskCluster.I've spent perhaps a bit too long trying to get the to the root of the problem, before I put up this hacky fix. Here is what I know:
Localizer::getTranslatedCityName
, we have the following values on my machine onmain
branch:cityName Malmö / parsedCityName Malm / i18nCityId ServersMalm / value Μάλμε
. On TaskCluster (onmain
), we get the same ones with one exception - value isMalmö
.value
is created here, this seems to imply it's an issue with the translation that Qt is pulling out.<message id="servers.Malmö">
When building locally, I get the same thing. This is inbuild/translations/generated/mozillavpn_el.ts
. This makes sense, asservers.Malmö
is the string ID used in the translation repo.lconvert
to convert it to a binaryqm
file.qm
files are binary, and are somewhat of a black box to us.lconvert
or loading the files when running the client, special characters should get stripped out from the translation ID. And they are on my machine, but not on TaskCluster. In both cases, what happens at this level is somewhat unknown, as they get deep Qt's handling of translations - it's deeper than our translation scripts (for creating translation files or loading them into the client).The attached fix is hacky. I hate it. It's not generalizable. While we currently only have one server with a special character, if we ever got another one we'd need to replicate this fix for it. It's also deep in a build script, and is not immediately obvious where/how this is handled.
However, I chose this option for two reasons:
A. We rarely add new servers, and thus the liklihood of adding a new server with a special character in the name is minimal. It may happen once every many years, but isn't something we'll deal with regularly.
B. We could hackily change the string ID when pulling strings out into the translation repo. That would at least keep the ID as
servers.Malm
for most of the round trip journey from our client repo to the translation repo and back. However, this would mean that we'd lose the existing translation for Malmö, and translators would need to re-translate it under the new string ID. I wanted to avoid that.Feel free to reject this PR, if you don't like the hacky solution here. I'm open to other methods, especially changing the string ID before it's sent to the translation repo (which comes with the downside of B above).
Reference
VPN-6649
Checklist