Oscar Manuel Gómez Senovilla Reporter
	Description • 21 years ago

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.

	Dave Miller [:justdave]
	Comment 1 • 21 years ago

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.

	Dave Miller [:justdave]
	Comment 2 • 21 years ago

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)

	J. Paul Reed [:preed]
	Comment 3 • 21 years ago

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

	Oscar Manuel Gómez Senovilla Reporter
	Comment 4 • 21 years ago

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?

	Dave Miller [:justdave]
	Comment 5 • 21 years ago

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.

	Oscar Manuel Gómez Senovilla Reporter
	Comment 6 • 21 years ago

The language is "es" all the time.

	Oscar Manuel Gómez Senovilla Reporter
	Comment 7 • 21 years ago

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.

	J. Paul Reed [:preed]
	Comment 8 • 21 years ago

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

Probably.

	Oscar Manuel Gómez Senovilla Reporter
	Comment 9 • 21 years ago

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

	J. Paul Reed [:preed]
	Comment 10 • 21 years ago

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

	Oscar Manuel Gómez Senovilla Reporter
	Comment 11 • 21 years ago

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.

	Max Kanat-Alexander
	Comment 12 • 20 years ago

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.

	Frédéric Buclin Assignee
	Comment 14 • 18 years ago

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

	timeless
	Comment 16 • 17 years ago

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.

	Frédéric Buclin Assignee
	Comment 17 • 17 years ago

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.

	timeless
	Comment 18 • 17 years ago

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

	Frédéric Buclin Assignee
	Comment 20 • 17 years ago

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.

	timeless
	Comment 21 • 17 years ago

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?

	Frédéric Buclin Assignee
	Comment 22 • 17 years ago

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

	Marc Schumann [:Wurblzap]
	Comment 23 • 17 years ago

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.

	Frédéric Buclin Assignee
	Comment 24 • 17 years ago

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

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

	Max Kanat-Alexander
	Comment 25 • 17 years ago

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

	Emmanuel Seyman
	Comment 26 • 17 years ago

I feel this is somewhat important.
Requesting blocking3.2

	Max Kanat-Alexander
	Comment 27 • 17 years ago

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.

	Frédéric Buclin Assignee
	Comment 28 • 17 years ago

/me keeps an eye on this one.

	Phil
	Comment 30 • 16 years ago

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

	Max Kanat-Alexander
	Comment 31 • 16 years ago

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

	Vitaly Fedrushkov
	Comment 32 • 16 years ago

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

	Phil
	Comment 33 • 16 years ago

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

	Vitaly Fedrushkov
	Comment 35 • 16 years ago

See also bug 466968

	fedor ezeev
	Comment 36 • 15 years ago

See also bug 376984

	mailtrader
	Comment 37 • 14 years ago

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.

	Frédéric Buclin Assignee
	Comment 38 • 14 years ago

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

	Frédéric Buclin Assignee
	Comment 39 • 14 years ago

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

	Max Kanat-Alexander
	Comment 40 • 14 years ago

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

	mailtrader
	Comment 41 • 14 years ago

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

	Max Kanat-Alexander
	Comment 42 • 14 years ago

  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.

	mailtrader
	Comment 43 • 14 years ago

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

	Max Kanat-Alexander
	Comment 44 • 14 years ago

  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.

	mailtrader
	Comment 45 • 14 years ago

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

	Max Kanat-Alexander
	Comment 46 • 14 years ago

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

	Frédéric Buclin Assignee
	Comment 47 • 14 years ago

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.

	Frédéric Buclin Assignee
	Comment 48 • 14 years ago

Done!