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

Status: RESOLVED FIXED

(Bugzilla :: Email Notifications, defect, P1)

Description

[Oscar Manuel Gómez Senovilla]

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


[e-mail] changed:

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




------- Additional Comments From [e-mail]  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.

Comment 1

[Dave Miller [:justdave]]

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.

Comment 2

[Dave Miller [:justdave]]

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)

Comment 3

[J. Paul Reed [:preed]]

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. :-)

Comment 4

[Oscar Manuel Gómez Senovilla]

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?

Comment 5

[Dave Miller [:justdave]]

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.

Comment 6

[Oscar Manuel Gómez Senovilla]

The language is "es" all the time.

Comment 7

[Oscar Manuel Gómez Senovilla]

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.

Comment 8

[J. Paul Reed [:preed]]

Oscar: bug 84876 is the focus right now, but email prefs is important; it'll get
into 2.18.

Probably.

Comment 9

[Oscar Manuel Gómez Senovilla]

Well, should this bug depend on bug 84876? I think so.

Comment 10

[J. Paul Reed [:preed]]

Oscar: It should depend on bug 100089, actually. Which it already does.

Comment 11

[Oscar Manuel Gómez Senovilla]

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.

Comment 12

[Max Kanat-Alexander]

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 [e-mail] 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.

Comment 14

[Frédéric Buclin]

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");

Comment 16

[timeless]

Attachment: round one

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.

Comment 17

[Frédéric Buclin]

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.

Comment 18

[timeless]

Attachment: round one diff'd from the right directory

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 :).

Comment 20

[Frédéric Buclin]

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.

Comment 21

[timeless]

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?

Comment 22

[Frédéric Buclin]

(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.

Comment 23

[Marc Schumann [:Wurblzap]]

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 24

[Frédéric Buclin]

Comment on attachment 273352 [details] [diff] [review]
round one diff'd from the right directory

r- per my previous comment + Marc's one.

Comment 25

[Max Kanat-Alexander]

Now that we have multiline_sprintf, it could be made into a template filter and things could work that way.

Comment 26

[Emmanuel Seyman]

I feel this is somewhat important.
Requesting blocking3.2

Comment 27

[Max Kanat-Alexander]

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.

Comment 28

[Frédéric Buclin]

/me keeps an eye on this one.

Comment 30

[Phil]

So it won't be included in 3.2, will it? Or is the target milestone still valid?

Comment 31

[Max Kanat-Alexander]

Yeah, at this point this will be too much change to go into 3.2.

Comment 32

[Vitaly Fedrushkov]

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?)

Comment 33

[Phil]

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?)
> 

Comment 35

[Vitaly Fedrushkov]

See also bug 466968

Comment 36

[fedor ezeev]

See also bug 376984

Comment 37

[mailtrader]

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.

Comment 38

[Frédéric Buclin]

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!).

Comment 39

[Frédéric Buclin]

Not a blocker for 4.0, but something we may take if fixed on time.

Comment 40

[Max Kanat-Alexander]

This is definitely do-able now, too, since we have template_var.

Comment 41

[mailtrader]

(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...

Comment 42

[Max Kanat-Alexander]

  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.

Comment 43

[mailtrader]

(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...

Comment 44

[Max Kanat-Alexander]

  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.

Comment 45

[mailtrader]

(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).

Comment 46

[Max Kanat-Alexander]

(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.

Comment 47

[Frédéric Buclin]

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.

Comment 48

[Frédéric Buclin]

Done!