Closed Bug 481966 Opened 14 years ago Closed 14 years ago

l10n needs different entities for 'to: you' and 'from: you' in message header


(Thunderbird :: Message Reader UI, defect, P1)



(Not tracked)

Thunderbird 3.0b4


(Reporter: Thunderbird_Mail_DE, Assigned: dmosedale)



(Whiteboard: [has l10n impact])


(1 file, 2 obsolete files)

Bug 456818 introduced the entity headerFieldYou=You

As far as I can see, this one string is used for "to: you" and "from: you" in message header pane. In German and maybe in other languages we need an other string for "from: you", because it must be "An: Sie" and "Von: Ihnen".
Depends on: me-header
Blocking; this looks really clumsy in German.
Assignee: nobody → dmose
Flags: blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0rc1
Whiteboard: [affects l10n]
Target Milestone: Thunderbird 3.0rc1 → Thunderbird 3.0b4
Yesterday's accidental closure of the parent bug 478466 brought my attention back to this issue and the localization problem. The "headerFieldYou" is used deep down in AddExtraAddressProcessing() of msgHdrViewOverlay.js (the only occurence), which is called by updateEmailAddressNode(), in turn called by OutputEmailAddresses(), but also defined in mailWidgets.xml,and then this is somehow associated with the header names. Thus, each of those headers would have to be extended with a directional attribute to distinguish "to" and "from" context, assuming that this is the maximum case for all locales (are we sure that it is, or does this only shift the problem to other issues for other languages?). Then, that information has to ripple down the chain of calls to be considered in AddExtraAddressProcessing() again to take the correct variant. Sounds like a quite bit of overhead for a feature which - frankly - is rather questionable to start with...
Whiteboard: [affects l10n] → [has l10n impact]
Priority: -- → P1
It's not terribly pretty, thanks to the loveliness that is this code, but it's fortunately a little less painful than that.  Basically, my impl strategy is to simply attach the header name to the mail-emailaddress binding, and then in AddExtraAddressProcessing, use that name to parameterize the string that we get from the properties file.  If a header-specific string isn't found, we just fall back to generic one.
Whiteboard: [has l10n impact] → [has l10n impact][patch 1/2 done]
Attachment #398195 - Flags: review?(philringnalda)
Whiteboard: [has l10n impact][patch 1/2 done] → [has l10n impact][has patch; needs review]
Attached patch patch, v2 (obsolete) — Splinter Review
I evidently forgot to type "hg qrefresh" before I uploaded the last patch.  Here's the one I actually meant to upload!
Attachment #398195 - Attachment is obsolete: true
Attachment #398434 - Flags: review?(philringnalda)
Attachment #398195 - Flags: review?(philringnalda)
Attached patch patch, v3Splinter Review
That was a completely different wrong version, which appears to have come about due to Firefox pre-resolving symlinks and caching the result, so that if a symlink changes behind it's back, Bad Things Happen.  And again...
Attachment #398434 - Attachment is obsolete: true
Attachment #398437 - Flags: review?(philringnalda)
Attachment #398434 - Flags: review?(philringnalda)
Attachment #398437 - Flags: review?(philringnalda) → review+
Comment on attachment 398437 [details] [diff] [review]
patch, v3

r=me if you take out your trailing whitespace, though I was looking forward to the earlier "Youse" version :)
Trailing whitespace removed and pushed:

"Youse" is gonna have to wait for the en-NJ localization, I think.
Whiteboard: [has l10n impact][has patch; needs review] → [has l10n impact]
Closed: 14 years ago
Resolution: --- → FIXED
Blocks: me-header
No longer depends on: me-header
No longer depends on: 456818
You need to log in before you can comment on or make changes to this bug.