Mail notifications about statuses and resolutions still in english (not localizable)

RESOLVED FIXED in Bugzilla 4.2

Status

()

defect
P1
normal
RESOLVED FIXED
16 years ago
9 years ago

People

(Reporter: omgs, Assigned: LpSolit)

Tracking

({l12y})

2.17.4
Bugzilla 4.2
Dependency tree / graph
Bug Flags:
blocking4.0 -
blocking3.2 -

Details

(Whiteboard: [fixed by blocker])

Attachments

(1 attachment, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4) Gecko/20030625
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4) Gecko/20030625

This is the email I've received when marking as "A MI ME VALE" (WORKSFORME) my
bug nº 6:


http://bugzilla-cvs.omgs.homelinux.org/show_bug.cgi?id=6


oscar@omgs.homelinux.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




------- Additional Comments From oscar@omgs.homelinux.org  2003-06-08 01:31 CEST
-------
This works for me, but I think the bug can't be closed until this is implemented
in your bugzilla.

Reproducible: Always

Steps to Reproduce:



Expected Results:  
There are still many things to change:

- The word "changed" after the user name
- The line "What", "Removed", "Added"
- The text containing the text "Status", "Resolution" and the statuses and
resolutions themselves.
- The text "Additional Comments From"
- Optionally, the time format.
Blocks: 214907
Version: unspecified → 2.17.4
a) Mail notifications use activity log data.  Thus, this depends on localization
of the activity log.

b) Localizing the email requires that we get the email templatized first (it's
not yet).  I believe this is happening as part of bug 84876.
Status: UNCONFIRMED → NEW
Depends on: 84876, 215208
Ever confirmed: true
oof.  We'll need a user preference for what language their mail should be sent in.

We can't use the useragent trick for email since the person generating the email
may or may not speak the same language as the user receiving the mail.

(although there's not much we can do about the text of comments and so forth ;)
 but we can certainly localize the field names and so on)
Just a clarification, email templatization is happening as part of 84876, but
technically, that's bug 100089.

The UI pref for this shouldn't be a big deal either... we can make it part of
bug 73665. :-)
Depends on: 100089
No longer depends on: 84876
That bug has its last comment in 12-12-2002. It should be resurrected. :-)

Anyway, if you think you can't use "the browser trick" for email, what about a
user preference "use browser language for mail" (checked by default for not
breaking the existing accounts), and an option to choose a language if the
option is unchecked, that could be taken from the "$BUGZILLA/template" directory?
Then we'll need to record what browser language a user last used in their
profile so it'll be available to the mail code.
The language is "es" all the time.
J. Paul: as Simon said in http://bugzilla.mozilla.org/show_bug.cgi?id=73665#c24,
nobody seems to be working. Apart, I've seen that it was opened in bz 2.11, and
my starting point is 2.17.4, so I don't what differences are applied from bug
73665 (or any other related) to 2.17.4 (i.e. "nowadays"). Bug 84876 is more
active, but too technical for me :-(

Please take my comment 4. About what Dave says, I think that surely a "lang"
field could be added to the table where user prefs are stored (of course, any
idea where a user can store his/her preferred language is welcome). If the value
in that field is blank, then "leave language autodetection work", but if it has
a value (or even values), that could be the order thar would override the
language browser settings.
Oscar: bug 84876 is the focus right now, but email prefs is important; it'll get
into 2.18.

Probably.
Well, should this bug depend on bug 84876? I think so.
Oscar: It should depend on bug 100089, actually. Which it already does.
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.20
No longer depends on: 215208
I suggest, apart of what is being worked in bug 84876, that a workaround is
provided for, since detection is difficult, at least use the "defaultlanguage"
parameter, enabling this setting for email, too.
Depends on: 275636
No longer depends on: 100089
This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to nobody@bugzilla.org or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.
Target Milestone: Bugzilla 2.20 → ---
QA Contact: mattyt-bugzilla → default-qa
Assignee: myk → ui
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 297186
No, this is not fixed yet. Resolutions are still in english (taken as it from the DB without calling get_text() to get the translated resolution) and several strings are hardcoded in BugMail.pm itself, for instance:

 $diffheader .= FormatTriple("What    ", "Removed", "Added");

 $thisdiff =
   "\nBug $id depends on bug $depbug, which changed state.\n\n" .
   "Bug $depbug Summary: $summary\n" .
   "${urlbase}show_bug.cgi?id=$depbug\n\n";
 $thisdiff .= FormatTriple("What    ", "Old Value", "New Value");
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
Duplicate of this bug: 357278
Summary: Mail notifications about resolutions still in english → Mail notifications about statuses and resolutions still in english
Posted patch round one (obsolete) — Splinter Review
this doesn't completely solve the problem (and it raises a few issues, see especially Bugzilla::User::identity which is IMO buggy, but which I'm working around by creating another copy of).

I don't want to be forced to completely fix this bug in a single patch, I'd like to do this incrementally. I am fine with making my address method replace the identity method.
Assignee: ui → timeless
Status: NEW → ASSIGNED
Attachment #272924 - Flags: review?(LpSolit)
Comment on attachment 272924 [details] [diff] [review]
round one

This patch is obviously not complete as you introduce a 3rd param to get_text() and get_term() which are never used. Moreover, we already have User->identity. There is no need for User->address.
Attachment #272924 - Flags: review?(LpSolit) → review-
identity is buggy, the docs claims to return email addresses, but the impl and comment indicate that it doesn't.

since you seem to think it should do what i want, i'm changing the implementation :).
Attachment #272924 - Attachment is obsolete: true
Attachment #273352 - Flags: review?(LpSolit)
Duplicate of this bug: 389229
Comment on attachment 273352 [details] [diff] [review]
round one diff'd from the right directory

>Index: mozilla/webtools/bugzilla/template/en/default/global/variables.none.tmpl

>+  "Added" => "Added",
>+  "Who" => "Who",
>+  "What" => "What",
>+  "When" => "When",
>+  "Removed" => "Removed",
>+  "NewValue" => "New Value",
>+  "OldValue" => "Old Value"

I don't see why we should use variables.none.tmpl to store this information. Why not use a real email template? i.e. collect the data in BugMail.pm, and pass it to the template which will format everything correctly and in the right language, as we do everywhere else.
because i shouldn't have to change those strings more than once when i want to make a customization to their names.

as for making a proper template out of them, this is a stepping stone along the path. it's better than where we are. are you absolutely opposed to incremental changes?
(In reply to comment #21)
> because i shouldn't have to change those strings more than once when i want to
> make a customization to their names.

Unrelated. Each email template has a specific role. Strings do not need to be changes in more than one place.
I agree with Frédéric to keep these words out of variables.none.tmpl. There's a limit to what this file is good for, and I think this limit is somewhat earlier. We don't templatize attachment either.
Comment on attachment 273352 [details] [diff] [review]
round one diff'd from the right directory

r- per my previous comment + Marc's one.
Attachment #273352 - Flags: review?(LpSolit) → review-
Depends on: 391997
Now that we have multiline_sprintf, it could be made into a template filter and things could work that way.
I feel this is somewhat important.
Requesting blocking3.2
Flags: blocking3.2?
I can't *block* 3.2 on this, because it's really kind of a big change. I'd definitely like to see it happen, but I really do think we're going to be freezing soon, and I don't want to hold off the freeze for this.
Flags: blocking3.2? → blocking3.2-
/me keeps an eye on this one.
Target Milestone: --- → Bugzilla 3.2
Component: User Interface → Email Notifications
Priority: -- → P1
Duplicate of this bug: 434543
So it won't be included in 3.2, will it? Or is the target milestone still valid?
Yeah, at this point this will be too much change to go into 3.2.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
Just to complete a picture: a workaround, introduced by Bugzilla-pl team:

http://svn.aviary.pl/wsvn/Bugzilla/branches/3.0/template/pl/default/email/newchangedmail.txt.tmpl

This is a hack, not solution, but may serve as remedy until 4.0 (3.4?)
Thanks, I implemented something similar at our site.

(In reply to comment #32)
> Just to complete a picture: a workaround, introduced by Bugzilla-pl team:
> 
> http://svn.aviary.pl/wsvn/Bugzilla/branches/3.0/template/pl/default/email/newchangedmail.txt.tmpl
> 
> This is a hack, not solution, but may serve as remedy until 4.0 (3.4?)
> 

Duplicate of this bug: 439407
Keywords: l12y
Summary: Mail notifications about statuses and resolutions still in english → Mail notifications about statuses and resolutions still in english (not localizable)
Depends on: 457657
See also bug 466968
See also bug 376984
Ping. Our solution unfortunately changes every word in the whole message, so if we use:
[% diffspl = diffspl | replace('Component', 'Komponent') %] 
then TestComponent in TestProduct will be changed into TestKomponent.
As this bug is 7 (!) years old I think it is ridiculous that it is not fixed yet.
I just hope that this one and a lot of others will block Bugzilla 4 (I know that there is a plan to rename 3.8 to 4). 100% localization using just tmpl files (not touching the code of Bugzilla) is VERY important.
I doubt timeless is still working on it. If someone wants to fix this bug, feel free to attach a patch (based on Bugzilla 3.7.1!).
Assignee: timeless → email-notifications
Status: ASSIGNED → NEW
No longer depends on: 391997
Flags: blocking4.0?
Not a blocker for 4.0, but something we may take if fixed on time.
Flags: blocking4.0? → blocking4.0-
This is definitely do-able now, too, since we have template_var.
Target Milestone: Bugzilla 5.0 → Bugzilla 4.0
(In reply to comment #40)
> This is definitely do-able now, too, since we have template_var.
Cool to hear that. I hope this means that the dev team will change it's attitude toward 100% localizable product in 4.0 major version (as probably you know this is a "must have" for some organizations). Unfortunately reading comment #32 (wrote two years and two versions ago) I'm little skeptical...
  Hey Hakon. Just to let you know, we actually aren't opposed to having a 100% localizable product, at all! We really want that! :-) It's just been very difficult to get the code to a place where that was possible. The code is now pretty much there, but it does need some attention from a developer to actually make the l12y happen.
(In reply to comment #42)
> difficult to get the code to a place where that was possible. The code is now
> pretty much there, but it does need some attention from a developer to actually
> make the l12y happen.

Cool to hear that, but even now some messages outputed to the console during the instalation process still are not localizable. It would be great to add "does your code is 100% localizable? does bz's perl module [putnamehere] output localizable strings?" checks in future versions of this product and therefore we, translators, wouldn't have to spend afternoons hacking the templates (or patching pm files) to display translated values...
  Ah, yeah. Well, some of the checksetup.pl messages may never be localizable, but any message that the user has to actually read and understand should be localizable. There's a framework in place for it--the messages just have to be moved there.

  A test is a possibility, but it would be pretty hard, since we don't have much of a testing framework to start with, and because localizing Bugzilla is hard, so it would be hard to create a "test" localization purely for testing.
(In reply to comment #44)
>   A test is a possibility, but it would be pretty hard, since we don't have
> much of a testing framework to start with, and because localizing Bugzilla is
> hard, so it would be hard to create a "test" localization purely for testing.

Well, even some kind of manual which end with "l10n passed" flag would be enough. Every localization project that is synchronized with Bugzilla trunk could be involved during developement of new features (and catching up old ones).
Depends on: 396558
Depends on: 466968
(In reply to comment #45)
> Well, even some kind of manual which end with "l10n passed" flag would be
> enough. Every localization project that is synchronized with Bugzilla trunk
> could be involved during developement of new features (and catching up old
> ones).

  Yeah, if you want to work with SnowyOwl (the l10n lead) and LpSolit (the QA Lead) to make that happen, you're welcome to post to the developers list about it.
I have fixed this bug as part of bug 466968. Bugmails will now be 100% localized. I will close this bug once I have uploaded my patch to bug 466968 and committed it. (Uploaded patch: probably later today; I'm almost done with it, including testing. Commit: I hope next week, depending on the reviewer.)

But the patch is so invasive (everything is currently hardcoded in BugMail.pm) that this bug will only be fixed on trunk, i.e. Bugzilla 4.2.
Assignee: email-notifications → LpSolit
Status: NEW → ASSIGNED
Whiteboard: [fixed by blocker]
Target Milestone: Bugzilla 4.0 → Bugzilla 4.2
Done!
Status: ASSIGNED → RESOLVED
Closed: 13 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.