User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/419 (KHTML, like Gecko) Safari/419.3 Build Identifier: Bugzilla 3.0rc1 Change the variables.none.tmpl Bug to "Issue" and the resulting emails notifciations will be [Issue #] going out of bugzilla, but email_in.pl is hard coded to look for [Bug #] in the subject. Reproducible: Always Steps to Reproduce: 1. Change variables.none.tmpl 2. Respond to an email 3. Get a new bug created since the 'bug_id' is not set Actual Results: Get a new bug created Expected Results: Expected existing bug to be updated

Patch to use get_text similar to Bugzilla/Template.pm for linkification of the bug_word.

According to http://www.bugzilla.org/docs/reviewer-list.html#scripts, mkanat@bugzilla.org is the proper reviewer for this file. Please request review from him. To do this, click "Details" next to the attachment, select '?' from the drop-down box next to "review", and enter "mkanat@bugzilla.org" as the requestee address.

I can confirm that I have run into this bug in our installation of bugzilla 3.0rc1. We've worked around it for now but it would be nice if this were addressed in an official version.

I can confirm this bug too. Bugzilla 3.0.1. This bug touch not only customization, but localisation too. Some words about localization. It would be nice to have two version of 'bug' term: one from variables.none.tmpl, and one hardcoded (?) 'Bug'. Becourse ordinar users prefer use translated word, but developers often prefer use english.

Not a blocker. But I might be still willing to take it on the 3.0 branch if it's done before then.

Comment on attachment 261096 [details] [diff] [review] email_in.pl patch to use get_text for bug word >+ my $bug_word = get_text('term', { term => 'Bug' }); >+ if ($summary =~ /\[$bug_word (\d+)\](.*)/i) { That needs to be \Q$bug_word\E >+ # see if the term for a bug is being used for the id >+ $current_field = lc($bug_word); >+ if ($fields{$current_field}) { >+ $fields{'bug_id'} = $fields{$current_field}; >+ delete $fields{$current_field}; No, the field names are an API, they don't get localized.

(In reply to comment #7) > No, the field names are an API, they don't get localized. My laziness factor kicks in - since the localized fields names in the email are what goes out and this is how you can just reply to the email and have the lookup work if you changed away from "Bug"... Basically, do you have a suggestion so that if you see a [Issue 1234] in the email and just reply to update the report without doing current field replacement?

I'm not sure what you're talking about, because $fields will never contain 'Bug' or 'Issue' as a key, only bug_id, always.

By the way, another words about localization. There is a setting in user preferences, named "Language used in email" (placed on the "General preferences" tab). In other words, Bugzilla may send emails to different users in different languages. And any user must have (I think so) a possibility to comment a Bug with just reply on the Bugzilla message without changing a Subject field. So, there is a point of talking before coding: 1. Bugzilla sends emails with term 'Bug' only from "template/en/global/variables.none.tmpl". or 2. Bugzilla, when recieve email, search for term 'Bug' from all installed templates (languages).

(In reply to comment #9) > I'm not sure what you're talking about, because $fields will never contain > 'Bug' or 'Issue' as a key, only bug_id, always. > This was so long ago, I forgot what the patch did... This was a request from the team that since we made "bug" into "issue" - they could do @issue instead of @bug_id... Yeah, if you don't want that as part of your api - then, totally agree... The first part of the patch is all I really cared about getting back into the main bugzilla, was just the term fix - so, if you replied to the the email with [Issue 1234], it would update the bug correctly...

(In reply to comment #11) > The first part of the patch is all I really cared about getting back into the > main bugzilla, was just the term fix - so, if you replied to the the email with > [Issue 1234], it would update the bug correctly... Yeah, that's fine. :-) (In reply to comment #10) > So, there is a point of talking before coding: > [snip] It should search for the term only from their listed preferred language. You should also update the docs to mention this. You may have to somehow modify get_text to accomplish this. (Just CC'ing a localizer in case this somehow doesn't make sense to him.)

Looks like it worked on the internal staging server. This is all I wanted.

Comment on attachment 279148 [details] [diff] [review] patch to just get the localized Bug term from the Subject This will always pick the English version.

(In reply to comment #12) > It should search for the term only from their listed preferred language. What Max says makes sense. (I didn't look at the patch.)

There is a temporary workaround in localized version of the problem: Set Default Preferences - Language used in email - 'en' And set off 'Enabled' flag. There is no localized emails now, but users may comment bugs with just reply.