When I try to quit the native app "Sketch" I get a native dialog that contains the message: "This page is asking you to confirm that you want to leave - data you have entered may not be saved." Like this, presumably there are other FF dialogs that refer to the app as a "page". Is it easy to modify xul/ff and change the wording from "page" to "app"?

WebRT/XulRunner issue, could probably be solved with a custom WebRT.

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/24808723

We should decide which strings to fix, they're in a lot of places (mainly under dom/).

There's a variety of aspects of webapprt that request that it's a tad different to just desktop. I think I'd appreciate if this was a deep and real fix, i.e., some change to what string bundle does. Or that we refactor the strings that just happen to be in DOM from those that users are hardly ever going to see. That's also in the light of the discussion we're having in firefox-dev about splitting the strings that users see from those that are just in the error console or something.

Override appstrings.properties and dom.properties in webapprt, changing the language to say "application" instead of "page" where appropriate.

Application for testing some of the changed strings, one from appstrings.properties and one from dom.properties. Read the included readme; requires Twisted, which is pre-installed on Mac OS X and Ubuntu.

Hey Donovan, I proposed this approach to Axel at the beginning, but he didn't like it (his alternative ideas are in comment 5). You should probably ask his feedback too.

Thanks Marco. I read comment 5, but I don't understand what it entails. I just used the same approach that b2g used. Axel, can you provide more info about how you think it should be done? Could it be done in a different bug, if it is a lot more work than what I just did?

Comment on attachment 8343212 [details] [diff] [review] webapprt-change-strings.patch As Axel notes, the runtime is not just another kind of browser, so there are deeper issues with the strings (and the UI in which they appear) than the one being addressed here. In particular, some of the runtime's UI will want to identify itself as belonging to the runtime, while other UI will want to appear to be part of the application; and perhaps some UI shouldn't appear at all. Nevertheless, this fix is a notable improvement to the current behavior of the runtime, and it's a discrete change that doesn't preclude us from making additional changes. So it's worth doing, even if it isn't a complete solution to the deeper issues; and we should move forward with it while also continuing the conversation with Axel about the more substantive changes we should also make.

I wish this amount of strings wouldn't land so close to merge day. appstrings.properties > deniedPortAccess=The application tried to access a network port that it should not have access to. The application has canceled the request for your protection. This doesn't make sense: the application first tries to access a forbidden network port, then it stops itself? I guess it's something else stopping the application. Or you could solve it by saying "The request was canceled for your protection". > contentEncodingError=The application recieved a response from a server which used an invalid or unsupported form of compression. Typo: received. The first fix would require a new string ID (now checking dom.properties, it will take a while).

dom.properties Only 6 strings changed from the original in /dom > MediaDecodeAudioDataUnknownError=An unknown error occured while processing decodeAudioData. AFAIK typo (should be "occurred"). The nice part is that this spread everywhere http://transvision.mozfr.org/?repo=central&sourcelocale=en-US&locale=it&search_type=strings&recherche=occured

(In reply to Francesco Lodolo [:flod] from comment #12) > I wish this amount of strings wouldn't land so close to merge day. Whoops, sorry about that.. I'm not used to the normal firefox trains since I have been working on Firefox OS for so long. Should we revert this and re-apply it once the next train goes out?

(In reply to Donovan Preston [:fzzzy] from comment #15) > (In reply to Francesco Lodolo [:flod] from comment #12) > > I wish this amount of strings wouldn't land so close to merge day. > > Whoops, sorry about that.. I'm not used to the normal firefox trains since I > have been working on Firefox OS for so long. Should we revert this and > re-apply it once the next train goes out? No, at this point we're on merge day, so it's too late. Problem is that fixes for previous comments (should I file follow-ups?) will have to ride the trains ;-)

So do all new additions to dom/locales/en-US/chrome/dom/dom.properties need to be added to this file too, even though only 6 strings need to be different? If so, note that I almost missed this file's existence just now, and was saved by an accidental MXR search. And none of my reviewers would have known about this fork, since no one bothered to tell any of them about it... If all such additions (and they happy _all_ the time) need to go in here too, then we need some education and documentation (and ideally automation!) to that effect. If not, then why did the unchanged strings get copied too?

> and they happy _all_ the time "happen", of course.

I guess my original needinfo cleared itself by now, but to bz' point: We're not falling back between the override file and the original, so if the override doesn't have full coverage of the original, there needs to be a in-depth understanding that the code paths using that string can't be reached in the product in question.

OK. Since that last condition totally doesn't hold, we need to do something to ensure that the two files stay in sync. Do we have any existing tooling for that? If not, can we just unfork and modify the strings in the original file to work for both contexts? If that's not an option, can we refactor this file so that the strings in question are in their own .properties file (which, looking at those strings, wouldn't change very often) and not mixed in with the very transient warning strings?

I just verified that unfortunately, strings that are missing from the override file do not fall back to the original file. It would be nice if the mechanism of overriding the .properties files fell back to the original if the override did not define a certain string. I know nothing about the mechanism used here though, so I have no idea how much work that would be. The ideas bz has about either modifying the strings to work for both contexts or refactoring the .properties files into two files with frequently changing strings seem like good ideas to me. I still would like to understand what Axel was proposing in comment 5; is there a change which would make overriding unnecessary or less painful?

(In reply to Boris Zbarsky [:bz] from comment #20) > OK. Since that last condition totally doesn't hold, we need to do something > to ensure that the two files stay in sync. > > Do we have any existing tooling for that? I don't think we have tooling, but the conventional low-tech approach is to put a note in each file reminding folks to modify the strings in both. > If not, can we just unfork and > modify the strings in the original file to work for both contexts? We may be able to do that, but I'm loathe to optimize the strings for generality, since that will make them harder to understand, and it's already challenging enough to explain these technical concepts to regular users (and may be even harder some in other languages). > If that's not an option, can we refactor this file so that the strings in > question are in their own .properties file (which, looking at those strings, > wouldn't change very often) and not mixed in with the very transient warning > strings? We can do this, and this might be something like what Axel is suggesting in his second suggestion in comment 5. Alternately, we could move the strings to appstrings.properties, which is smaller, changes much less frequently (twice so far in 2013, whereas dom.properties has changed 37 times in the same time period), and for which there is precedent to override it (it is already overridden by Firefox, Fennec, and B2G). (In reply to Donovan Preston [:fzzzy] from comment #21) > It would be nice if the mechanism of overriding the .properties files fell > back to the original if the override did not define a certain string. I know > nothing about the mechanism used here though, so I have no idea how much > work that would be. I think this is Axel's first suggestion: modify the way string bundles work to handle overrides automatically. I like the idea, but it seems like a fair amount of work. (Also see the related idea in bug 937654.) > I still would like to understand what Axel was proposing in comment 5; is > there a change which would make overriding unnecessary or less painful? I too am very curious to get the details here. My reading of the comment is that Axel just has a general desire for a better solution (a sentiment I share). But if he does have a specific idea, and it's a reasonable amount of work, then let's do it! Otherwise, let's move the strings in question to appstrings.properties and add that file to the list in nsContentUtils <https://github.com/mozilla/gecko-dev/blob/326dca095450be5734328a48b09ebe0ffa2eb5a5/content/base/src/nsContentUtils.cpp#L2972-L2987> etc. so we can override them the same way we override the other strings in appstrings.properties. bz: you're a dom/ peer; how does that sound to you?

> put a note in each file reminding folks to modify the strings in both. I did consider that, but these files are way taller than my screen, so when you're adding a string at the end you wouldn't see the warning at the top. I guess we could try putting it at the bottom... I would be fine with moving the affected strings to appstrings.properties, yes.

FTR, I didn't have a concrete proposal in mind in comment 5. Or, truth be told, if I did, I don't remember.

Ok, good to know, thanks Axel :-)

I've filed bug 973958 to build a tool to make sure that the strings stay in sync.