1132071 - App Sharing: webrtcIndicator.sharingApplicationWithNTabs.menuitem string is using an improper plural form

Status: REOPENED

(Firefox :: Site Permissions, defect, P3)

Description

[Francesco Lodolo [:flod]]

This string landed in bug 1057006
http://hg.mozilla.org/mozilla-central/diff/ffc10f34de13/browser/locales/en-US/chrome/browser/webrtcIndicator.properties#l1.32

webrtcIndicator.sharingApplicationWithNTabs.menuitem = Sharing an Application with #1 tab;Sharing Applications with #1 tabs

Unfortunately this doesn't work for all locales: they need a number of "applications" to form the correct plural form, and AFAIK we can't have a plural form this complex (plural form is driven only by one variable, the number of tabs in this case).

Based on IRC discussion with Florian, it might also be not true that 1 tab=1 application.
My suggestion would be to use:

Sharing Applications with #1 tab;Sharing Applications with #1 tabs

Comment 1

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] from comment #0)
> Unfortunately this doesn't work for all locales: they need a number of
> "applications" to form the correct plural form

Are you saying there are locales that do not have a way to express "X>= 1 applications" where X is unknown? English just uses "applications", or perhaps "one or more applications" or something.

AIUI the code doesn't know the number of distinct applications being shared here (you could be sharing the same application with a number of tabs)

Comment 2

[:Gijs (he/him)]

So it seems the fundamental issue here is that we need to be clear that the number of applications is indeterminate, and be clear on that in the English. Francesco, do we need a different string ID to change that?

Comment 3

[Francesco Lodolo [:flod]]

(In reply to :Gijs Kruitbosch from comment #2)
> Francesco, do we need a different string ID to change that?

I think t's definitely safer. For example my brain completely ignored the second form and looked only at the first, so I have "application" in both forms.

http://transvision.mozfr.org/string/?entity=browser/chrome/browser/webrtcIndicator.properties:webrtcIndicator.sharingApplicationWithNTabs.menuitem&repo=aurora

Comment 4

[Ton [:Tonnes]]

(Pointed here as a result of bug 1142066.) Interesting, I'd say en-US should use the forms as they currently are in Italian, using singular "application" in both strings. 

(In reply to :Gijs Kruitbosch from comment #2)
> So it seems the fundamental issue here is that we need to be clear that the
> number of applications is indeterminate…

Is that true in both strings? If so, plurals for apps/tabs/windows in the first strings might be a better choice. But if not, I'd say there is 2 strings having 2 variables, which would require 4 strings instead. I.e. the 2 current ones tell us both the items to share and the items to share them with are either singular or plural, which may not be the case, right?

In other words: what needs to be pluralized here: one or more tabs to share with only, the number of apps/tabs/windows/(mics/cams/screens) only, or both? A brief l10 note for any of the 6 strings would help.

Comment 5

[:Gijs (he/him)]

(In reply to Ton from comment #4)
> (In reply to :Gijs Kruitbosch from comment #2)
> > So it seems the fundamental issue here is that we need to be clear that the
> > number of applications is indeterminate…
> 
> Is that true in both strings?

This question is ambiguous. Which (2) strings?

> If so, plurals for apps/tabs/windows in the
> first strings might be a better choice. But if not, I'd say there is 2
> strings having 2 variables, which would require 4 strings instead. I.e. the
> 2 current ones tell us both the items to share and the items to share them
> with are either singular or plural, which may not be the case, right?
> 
> In other words: what needs to be pluralized here: one or more tabs to share
> with only, the number of apps/tabs/windows/(mics/cams/screens) only, or
> both? A brief l10 note for any of the 6 strings would help.

The things we're sharing (apps/tabs/windows/mics/cams/screens) have different characteristics. AFAIK we can only ever share one mic/cam/"screen" (I don't know how we deal with multiple screen setups, but I'm pretty sure we do nothing to pass that info to l10n strings so we can just pretend there's only ever 1 screen for now), so we can assume that for all of these only 1 of each will be shared (obvs. it's still possible that both a camera and a microphone are being shared, but not 2 microphones or 5 cameras or whatever).

Regarding the applications, IIRC we don't know the number of unique applications in the multitab case, so it seems best to have an indeterminate plural for these as in comment #1.

Re-reading the strings, I think the English strings are just correct as-is?

    1.32 +webrtcIndicator.sharingApplicationWithNTabs.menuitem = Sharing an Application with #1 tab;Sharing Applications with #1 tabs

In the single tab case, you are only ever sharing 1 application. (although... iframes in the same tab? Florian?)

In the N tabs case, you could be sharing anywhere between 1 and N applications.

Florian, is this right? Should we just add an l10n note and leave it at that? Something else?

Comment 6

[Ton [:Tonnes]]

(In reply to :Gijs Kruitbosch from comment #5)
> > 
> > Is that true in both strings?
> 
> This question is ambiguous. Which (2) strings?

Both the singular and plural form strings (for tabs/windows/applications).

> The things we're sharing (apps/tabs/windows/mics/cams/screens) have
> different characteristics. AFAIK we can only ever share one mic/cam/"screen"

Clear about mic/cam/screen, hence parenthesized in comment 4.

> Regarding the applications, IIRC we don't know the number of unique
> applications in the multitab case, so it seems best to have an indeterminate
> plural for these as in comment #1.
> 
> In the single tab case, you are only ever sharing 1 application.
> (although... iframes in the same tab? Florian?)
> 
> In the N tabs case, you could be sharing anywhere between 1 and N
> applications.

So in the single tab case (i.e. when sharing X with one tab)), the number of applications/windows/tabs  to share will always be one? I imagined sharing multiple applications/windows/tabs with one single tab would also be possible. If not (and 100% sure), the current strings seem OK as is.

Comment 7

[Florian Quèze [:florian]]

(In reply to :Gijs Kruitbosch from comment #5)

> The things we're sharing (apps/tabs/windows/mics/cams/screens) have
> different characteristics. AFAIK we can only ever share one mic/cam/"screen"
> (I don't know how we deal with multiple screen setups, but I'm pretty sure
> we do nothing to pass that info to l10n strings so we can just pretend
> there's only ever 1 screen for now), so we can assume that for all of these
> only 1 of each will be shared (obvs. it's still possible that both a camera
> and a microphone are being shared, but not 2 microphones or 5 cameras or
> whatever).

For the screen case, we can currently only share the primary screen, but it's something that should be fixed eventually.

Sharing several different cameras and several different microphones with a single web page is possible. We can share only one video and/or audio stream per getUserMedia request, but a page can do another getUserMedia request after receiving streams from the previous one.

That said, I'm not convinced we should optimize the UI / the strings for cases that are technically possible, but realistically unlikely to happen.


>     1.32 +webrtcIndicator.sharingApplicationWithNTabs.menuitem = Sharing an
> Application with #1 tab;Sharing Applications with #1 tabs
> 
> In the single tab case, you are only ever sharing 1 application.
> (although... iframes in the same tab? Florian?)

Even without using iframes, it's possible for a web page to call getUserMedia several times, and get streams for different applications at once.


> Should we just add an l10n note and leave it at that? Something else?

I guess adding l10n notes can't hurt. I don't think making the strings perfectly accurate for the edge case of several cameras/apps being shared is worth the time of implementing it, but I could be convinced otherwise (eg. I would be willing to review a patch for it).

Comment 8

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.