Closed Bug 840888 Opened 7 years ago Closed 7 years ago

en-US string review and doubts in browser/metro

Categories

(Firefox for Metro Graveyard :: General, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: flod, Assigned: mbrubeck)

References

Details

Attachments

(1 file)

/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?
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
Depends on: metro-browser
(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.
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.
Whiteboard: [metro-mvp?]
OS: Windows 8 → Windows 8 Metro
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.
(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).
No longer depends on: metro-browser
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.
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.
(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.
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.
(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.
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.
(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?
(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.
(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
Whiteboard: [metro-mvp?]
If there are specific issues, please file specific bugs. This bug is too general.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?
Resolution: --- → INCOMPLETE
No longer blocks: metrov1triage
Blocks: 852263
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.
Assignee: nobody → mbrubeck
Status: RESOLVED → REOPENED
Attachment #726758 - Flags: review?(jmathies)
Flags: needinfo?
Resolution: INCOMPLETE → ---
Attachment #726758 - Flags: review?(jmathies) → review+
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.
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.
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".)
Note: This reverts one of the string changes from bug 845096.

https://hg.mozilla.org/integration/mozilla-inbound/rev/046b3a4808b8
Status: REOPENED → ASSIGNED
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 ?
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?
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.
(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
https://hg.mozilla.org/mozilla-central/rev/046b3a4808b8
Status: ASSIGNED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.