Francesco Lodolo [:flod] Reporter
	Description • 12 years ago

/browser/metro/locales/en-US/chrome/browser.dtd

<!ENTITY contextVideoTab.label        "Open In New Tab">
I guess you want "in", not "In" according to other strings (e.g. "Open Link in New Tab" or "View in New Tab")



<!ENTITY contextSaveImageTo.label     "Save Image To">
<!ENTITY contextSaveVideoTo.label       "Save Video To">

Is there a specific reason for choosing "save X to" instead of "save X as"? Is that form used in Metro IE for example?



/browser/metro/locales/en-US/chrome/browser.properties
browserForSaveLocation=Save Location

Care to explain where and how this string is used? Location=geolocation or location=url address
A localization comment would be useful



/browser/metro/locales/en-US/overrides/passwordmgr.properties
hidePasswordsAccessKey=P 
(and others in this file)
/browser/metro/locales/en-US/chrome/browser.dtd
<!ENTITY urlbar.accesskey      "d">

Are accesskeys available/usable in Metro?

	Francesco Lodolo [:flod] Reporter
	Comment 1 • 12 years ago

Not sure if it's ok in this case, but adding dependency to bug 750903 considering that's the bug that merged everything in central

	Francesco Lodolo [:flod] Reporter
	Comment 2 • 12 years ago

(In reply to Francesco Lodolo [:flod] from comment #0)
> Care to explain where and how this string is used? Location=geolocation or
> location=url address
> A localization comment would be useful

I guess that's the title of the dialog used to save an item, so none of the above :-\
https://hg.mozilla.org/mozilla-central/rev/a85a2ddb41bf#l5.238

Definitely need a localization comment.

	Jim Mathies [:jimm]
	Comment 3 • 12 years ago

Ux may tweak the strings before we get to Aurora. For example the context menu strings are currently being reviewed by Asa although we don't have a bug on it yet. For access keys, yes, metro like desktop has keyboard input support.

	Axel Hecht [:Pike]
	Comment 4 • 12 years ago

Ugh, we shouldn't land strings and then get UX review. Spilled milk, but this is just wasting a ton of work in our l10n community.

	Francesco Lodolo [:flod] Reporter
	Comment 5 • 12 years ago

(In reply to Jim Mathies [:jimm] from comment #3)
> For access keys, yes, metro like desktop has keyboard input support.
Thanks Jim, then the question should be: why are 5/8 of these accesskeys empty?


>Ux may tweak the strings before we get to Aurora.
If you plan to change these strings (not accesskeys), I hope you're aware that you'll have to replace also key names as well (and the code that uses them).

	Asa Dotzler [:asa]
	Comment 6 • 12 years ago

Lots of strings are going to be added and some changed. That's the way it's going to be with Metro Firefox for a while. This is mozilla-central and as far as I understand things, we're under no obligation to have any kind of stable strings here.

	Axel Hecht [:Pike]
	Comment 7 • 12 years ago

Sorry, but landing code just to change it is just bad engineering.

And yes, strings on mozilla central are there to be ready to ship at any point in time. At least that's the theory of the rapid release cycle.

	Asa Dotzler [:asa]
	Comment 8 • 12 years ago

(In reply to Axel Hecht [:Pike] from comment #7)
> Sorry, but landing code just to change it is just bad engineering.

Landing code to change it is the whole point of mozilla-central. If we didn't think it was going to change, we'd just ship it to our release audience right off of one of our developer's machines.  

Metro Firefox is going to move a lot like Android Firefox did, with lots of churn for a period while we get to a v1. It's going to be a bit unpleasant for folks who have become accustomed to the slow and methodical pace of our version 20 products like desktop Firefox.

	Axel Hecht [:Pike]
	Comment 9 • 12 years ago

Well, it's your desktop product you're putting at risk. Noteworthy, as of today, we're not shipping a fully localized product on Android, I'd be cautious to use that as an example.

	Francesco Lodolo [:flod] Reporter
	Comment 10 • 12 years ago

(In reply to Asa Dotzler [:asa] from comment #8)
> It's going to be a bit unpleasant for folks who have become accustomed
> to the slow and methodical pace of our version 20 products like 
> desktop Firefox.

"folks" who localize Firefox as volunteers, and in less than a week will find 290 strings to localize on Aurora. Please be respectful of those people and their efforts.

	Robert Kaiser
	Comment 11 • 12 years ago

And when you change strings on m-c you still need to change the string IDs as well or most localizers will not pick up the changes in their localizations. As long as you're aware of that, the strings changes are "only" more work for them.

	Jim Mathies [:jimm]
	Comment 12 • 12 years ago

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #11)
> And when you change strings on m-c you still need to change the string IDs
> as well or most localizers will not pick up the changes in their
> localizations. As long as you're aware of that, the strings changes are
> "only" more work for them.

Hmm, that seems kinda broken. Shouldn't the tools localizers use pick up changes in the original string they translated?

	Robert Kaiser
	Comment 13 • 12 years ago

(In reply to Jim Mathies [:jimm] from comment #12)
> Hmm, that seems kinda broken. Shouldn't the tools localizers use pick up
> changes in the original string they translated?

Picking up relevant original string changes is extremely hard to do in practice, actually. Axel can probably tell you evening-filling stories on why we ended up with what we have in terms of process.
To change the string key on any change that needs localizer attention (not on English-only typos) has been the process for Mozilla for ages now, please just work by it.

	Francesco Lodolo [:flod] Reporter
	Comment 14 • 12 years ago

(In reply to Jim Mathies [:jimm] from comment #12)
> Hmm, that seems kinda broken. Shouldn't the tools localizers use pick up
> changes in the original string they translated?

Honestly this is a long discussion outside of the scope of this bug.

Guideline for string changes (and FYI Aurora is supposed to be string frozen): https://developer.mozilla.org/en-US/docs/Making_String_Changes

	Jim Mathies [:jimm]
	Comment 15 • 11 years ago

If there are specific issues, please file specific bugs. This bug is too general.

	Matt Brubeck (:mbrubeck) Assignee
	Comment 16 • 11 years ago

Let's reopen this bug and use it to address the specific issues from comment 0.  We can file new bugs for any other specific issues.

(In reply to Francesco Lodolo [:flod] from comment #0)
> <!ENTITY contextVideoTab.label        "Open In New Tab">
> I guess you want "in", not "In" according to other strings (e.g. "Open Link
> in New Tab" or "View in New Tab")

I believe we are now using sentence case consistently for all context menu labels.  We started documenting these standards at: https://wiki.mozilla.org/Firefox/Windows_8_Metro_Style_Guides

> <!ENTITY contextSaveImageTo.label     "Save Image To">
> <!ENTITY contextSaveVideoTo.label       "Save Video To">
> 
> Is there a specific reason for choosing "save X to" instead of "save X as"?
> Is that form used in Metro IE for example?

Yes, Metro apps like Metro IE use offer "Save to <library>" commands, which use a different UI from the classic/desktop "Save as..." dialogs.

The strings above have been replaced, and the new ones have a localization comment.  This patch updates the comment to use the standard LOCALIZATION NOTE format, and fixes a typo.

> browserForSaveLocation=Save Location
> 
> Care to explain where and how this string is used?

Added a localization note.

Also added some other localization notes that I hope will be helpful.

> Are accesskeys available/usable in Metro?

Yes, accesskeys work in Metro, though we haven't yet added accesskeys for many elements in our Metro UI.

	Francesco Lodolo [:flod] Reporter
	Comment 17 • 11 years ago

Thanks, this is a lot better.

In the next days I'll try to take a look in the strings and see if I can spot something wrong.

	Francesco Lodolo [:flod] Reporter
	Comment 18 • 11 years ago

browser.properties
clearPrivateData.message=Delete your browsing history and settings, including passwords and cookies?

That "settings" sounds a little scary (I don't think clear private data on Metro UI works differently from the standard browser).

sync.dtd
<!ENTITY sync.pair.description2     "To activate your new device, select &#x0022;Set up sync&#x0022; on the device.">

I'm pretty sure you want "Set up Sync" here, considering that Sync is the name of the feature.

	Matt Brubeck (:mbrubeck) Assignee
	Comment 19 • 11 years ago

Thanks for taking the time to review our strings!

(In reply to Francesco Lodolo [:flod] from comment #18)
> clearPrivateData.message=Delete your browsing history and settings,
> including passwords and cookies?
> 
> That "settings" sounds a little scary (I don't think clear private data on
> Metro UI works differently from the standard browser).

The "Clear Private Data" button really does clear everything -- as it did in old versions of Fennec.  But we plan to replace this in bug 845484 with something closer to the current desktop and Android interfaces.  I'll make that block bug 852236 since it will replace a couple of existing strings with new ones.

> <!ENTITY sync.pair.description2     "To activate your new device, select
> &#x0022;Set up sync&#x0022; on the device.">
> 
> I'm pretty sure you want "Set up Sync" here, considering that Sync is the
> name of the feature.

Good point; I will change the capitalization here.  Since this string was added after bug 844068 landed, I won't bother changing its name again - there shouldn't be any existing translations to update.

(Officially the feature name is "Firefox Sync" -- but we shorten in to "Sync" in a few places in the desktop and Android UI like "Set up Sync", "could not connect to Sync", and "Sync encountered an error".)

	Matt Brubeck (:mbrubeck) Assignee
	Comment 20 • 11 years ago

Note: This reverts one of the string changes from bug 845096.

https://hg.mozilla.org/integration/mozilla-inbound/rev/046b3a4808b8

	Alexander L. Slovesnik
	Comment 21 • 11 years ago

browser.properties
popupWarning=%S prevented this site from opening a pop-up window.
popupWarningMultiple=%S prevented this site from opening %S pop-up windows.

Can you convert these strings to proper plurals as written on https://developer.mozilla.org/en/docs/Localization_and_Plurals ?

	Alexander L. Slovesnik
	Comment 22 • 11 years ago

browser.properties
alertCantOpenDownload=Can't open file. Tap to save it.

"Tap" sounds like touchscreen-specific term. I guess metro is not limited to touchscreen devices only?

	Matt Brubeck (:mbrubeck) Assignee
	Comment 23 • 11 years ago

Could you please open a new bug for any new string issues?  This bug will be marked resolved once the patches land, so we'll want a separate bug to make it easier to track any still-open problems.

(In reply to Alexander L. Slovesnik from comment #22)
> "Tap" sounds like touchscreen-specific term. I guess metro is not limited to
> touchscreen devices only?

Like Firefox for Android, Firefox for Metro is usable with a mouse or trackpad but is really optimized for touch screens.  Our documentation and UI will probably emphasize touch over mouse (just as desktop strings sometimes say "click" even though some people use it with alternate input methods).

That particular string will probably go away when bug 831942 is implemented.

	Alexander L. Slovesnik
	Comment 24 • 11 years ago

(In reply to Matt Brubeck (:mbrubeck) from comment #23)
> Could you please open a new bug for any new string issues?  This bug will be
> marked resolved once the patches land, so we'll want a separate bug to make
> it easier to track any still-open problems.
 
Francesco has filed Bug 853126 for Comment 21

	Ed Morley [:emorley]
	Comment 25 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/046b3a4808b8