Closed Bug 1378713 Opened 8 years ago Closed 6 years ago

Stop exposing strings for about:networking to localization

Categories

(Core :: Networking, enhancement, P2)

Product:
Core
Component:
Networking
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: flod, Unassigned)

References

Details

(Whiteboard: [necko-next])

For a while I've seen strings landing for this page without explanation or comments. I'm having a hard time understanding what the last landed strings from bug 1377568 even mean in English (I'm sure they're clear enough to those who know the subject) https://hg.mozilla.org/mozilla-central/diff/655965b07027/toolkit/locales/en-US/chrome/global/aboutNetworking.dtd I believe this is an extremely technical page, with a limited target audience, and we should stop asking localizers to translate these strings.
(In reply to Francesco Lodolo [:flod] from comment #0) > For a while I've seen strings landing for this page without explanation or > comments. > > I'm having a hard time understanding what the last landed strings from bug > 1377568 even mean in English (I'm sure they're clear enough to those who > know the subject) > https://hg.mozilla.org/mozilla-central/diff/655965b07027/toolkit/locales/en- > US/chrome/global/aboutNetworking.dtd > > I believe this is an extremely technical page, with a limited target > audience, and we should stop asking localizers to translate these strings. I tend to agree with your evaluation. How do we stop exposing it to localization? Do we simply move all the strings out of the .dtd file into the UI?
Flags: needinfo?(francesco.lodolo)
(In reply to Valentin Gosu [:valentin] from comment #2) > I tend to agree with your evaluation. How do we stop exposing it to > localization? Do we simply move all the strings out of the .dtd file into > the UI? You can hard code them in the XHTML file, or move the DTD file out of toolkit/locales/en-US. The first solution seems easier to adopt.
Flags: needinfo?(francesco.lodolo)
Whiteboard: [necko-next]
It doesn't look more technical than devtools for me, do we really need to forbid localization of that UI?
(In reply to Stefan Plewako [:stef] from comment #4) > It doesn't look more technical than devtools for me, do we really need to > forbid localization of that UI? Devtools are exposed to users in the main UI, target a larger audience, strings have context. about:networking is a fairly hidden page used for debugging. For comparison, we don't localize about:memory.
(In reply to Francesco Lodolo [:flod] (PTO until Jul 17) from comment #5) > Devtools are exposed to users in the main UI, target a larger audience, > strings have context. > > about:networking is a fairly hidden page used for debugging. For comparison, > we don't localize about:memory. I don't get "fairly hidden" argument, if it is worth to keep that UI why would we make it only useful for English speaking users? Technical issues aside, many many strings have issues but that doesn't mean that Firefox should be en-US only.
I agree with Stefan. As a translator I should have the chance to translate **all** strings. I simply claim that every translator wants to translate all strings. It's the task of developers resp. "inventors" of the Engish strings to make them as simple as possible. The first thing is to avoid abbreviations that are explained nowhere, e.g. RCWN in about:networking. It is already difficult to understand technical terms but unkown abbreviations are fully unintelligible. Abbreviations can be used if they are written in full at least once so translators know what the abbreviations represent.
Localization teams should decide what they can or cannot handle (even if it's a temporary thing for lack of resources, language normalization process, ...). I would also expect every bit of the UI to be localizable. There could be a localization note, like for devtools, or some parts, that are deemed not so important for the overall experience, could be moved out of the way, to another Pontoon project. But they should still be localizable. I checked about:about and filed Bug #1385582.
I disagree, it shouldn't be a black and white approach. It should depend on the visibility and on the target of the message. about:memory and about:networking are perfect examples: if you're looking at those pages, you're either a developer trying to debug a problem, or you're talking with a developer trying to help you debugging that problem, in which case you need that information in English. Note that we had that complaint before, asking to not localize parts of about:support (bug 1343041). In that case I disagree, because it's a page used by standard users, and it should not have mixed content. I wouldn't object to splitting it off in a separate unlocalized about page though. (In reply to Eduardo Trápani from comment #10) > I would also expect every bit of the UI to be localizable. There could be a > localization note, like for devtools, or some parts, that are deemed not so > important for the overall experience, could be moved out of the way, to > another Pontoon project. The latter is not really an option, so let's start from the assumption that those strings will be exposed to all locales. Also, I think we're ignoring the main pain point here: most of you reached this bug because you couldn't understand what some of those strings mean. I don't think you can fix it by adding a couple of lines of localization notes, that localization file would need to turn into a Wikipedia page, given the niche nature of this topic.
(In reply to Francesco Lodolo [:flod] from comment #11) > I disagree, it shouldn't be a black and white approach. It should depend on > the visibility and on the target of the message. While I don't agree, it'd be easier to live with that if we knew each time you make the call. Then we could publicly disagree or simply thank you if we didn't want to translate that. But if just ab_CD would like to translate it ... maybe they should be able to and the rest of us would simply ignore the file. It could be a good start to make the policy clear, list the current state, and then communicate each time something is added and developers get the green light not to make content localizable from the start. > Note that we had that complaint before, asking to not localize parts of > about:support (bug 1343041). In that case I disagree, because it's a page > used by standard users, and it should not have mixed content. I agree with you on that one. I'd love to see a message in dev-l10n when you decide on those. If not it becomes a bit opaque. > Also, I think we're ignoring the main pain point here: most of you reached > this bug because you couldn't understand what some of those strings mean. I Because they weren't very well written, not just for localizers, but even for network oriented people outside of Mozilla. See comment #9 on acronyms usage. > don't think you can fix it by adding a couple of lines of localization > notes, that localization file would need to turn into a Wikipedia page, > given the niche nature of this topic. I'm very confident of my current translation and it only took a couple of lines you wrote in the mailing list (thanks!) to understand it clearly ... (I know, I might be building on _your_ visit to Wikipedia ;) but anyway, it didn't take a lot)
By the way, "stop exposing strings for about:networking" just doesn't look right now that it is localizable and there 40+ locales having done it. Are we going to be forced to get mixed context from now on if this bug is resolved fixed? If that's the outcome, it looks like overkill to me. I mean, just because somebody didn't write a couple of strings clearly?
If some terms are very obscures for translate, I consider it can uses tooltips for original or translated strings.
(In reply to Eduardo Trápani from comment #12) > While I don't agree, it'd be easier to live with that if we knew each time > you make the call. Then we could publicly disagree or simply thank you if we > didn't want to translate that. But if just ab_CD would like to translate it > ... maybe they should be able to and the rest of us would simply ignore the > file. To be clear: right now developers are making the call, it's not l10n making it. Nobody asked to make about:networking localizable at the time (bug 865850) or, on the other hand, to make other about: pages hard-coded. > It could be a good start to make the policy clear, list the current state, > and then communicate each time something is added and developers get the > green light not to make content localizable from the start. I agree, a clear policy would be a good start. In this case, I'm not sure it would have helped, the original content (an informative page about network requests) was a lot different that the one we have these days. > Because they weren't very well written, not just for localizers, but even > for network oriented people outside of Mozilla. See comment #9 on acronyms > usage. That's one of the points I'm trying to make. Were they "well written" enough for the target though? I don't know the answer to that. (In reply to Eduardo Trápani from comment #13) > By the way, "stop exposing strings for about:networking" just doesn't look > right now that it is localizable and there 40+ locales having done it. Are > we going to be forced to get mixed context from now on if this bug is > resolved fixed? > > If that's the outcome, it looks like overkill to me. I mean, just because > somebody didn't write a couple of strings clearly? Stop exposing = remove localization support for that page. It also means losing the content already translated, which we all agree it's far from good. That's why it would be important to make a call before more content is added to it. This page hasn't seen much activity in 4 years (10 commits), but 3 of them happened in the past 3 months https://hg.mozilla.org/mozilla-central/log/default/toolkit/locales/en-US/chrome/global/aboutNetworking.dtd
> To be clear: right now developers are making the call, it's not l10n making > it. Nobody asked to make about:networking localizable at the time (bug > 865850) or, on the other hand, to make other about: pages hard-coded. It's really helpful how you mention the bug numbers! So, they create something and then integrate it (UI-wise), but nobody asks you whether to make it localizable. And then you only see it when the strings show up in l10n. > Stop exposing = remove localization support for that page. Ok. I understand it now. > It also means losing the content already translated, which we all agree it's > far from good. That's why it would be important to make a call before more > content is added to it. Agreed.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P2
> abbreviations that are explained nowhere, e.g. RCWN in about:networking. It RCWN I _think_ this is to mean: Refresh (or: Redis;ay) Content When Needed ??
a collision: I found: or not https://bugzilla.mozilla.org/show_bug.cgi?id=1363700#c9 For posterity (people coming to this bug from the strings that just landed), RCWN stands for "Race Cache With Network" From bug 1358038 > The RCWN feature in Necko adds the ability to race the cache with > the network when the cache is slow. So if reading from the disk > is slow, we will send a network request, and return the channel > from the network, even though we have the entry in the cache. > This way we provide the content to consumers faster. so certainly worthy of formal definition on this about:networking page
:valentin based on comment #3 which next step do you recommend? Once I have that, I will assign this bug to be completed.
Flags: needinfo?(valentin.gosu)
In the meantime, we're in the process of moving this page to Fluent (bug 1504751), it should land within the next hours. Over one year ago it was clearer what to do, right now I'm not sure I want to throw all the work done away.
(In reply to Francesco Lodolo [:flod] from comment #22) > In the meantime, we're in the process of moving this page to Fluent (bug > 1504751), it should land within the next hours. > > Over one year ago it was clearer what to do, right now I'm not sure I want > to throw all the work done away. That's good to know. In that case maybe we want to close it as WONTFIX? (In reply to Selena Deckelmann :selenamarie :selena use ni? pronoun: she from comment #21) > :valentin based on comment #3 which next step do you recommend? Once I have > that, I will assign this bug to be completed. If we decide to go forward with this, I can probably write up a quick patch to hardcode the strings into the xhtml file.
Flags: needinfo?(valentin.gosu)
At this point, let's WONTFIX it.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.