From lpsolit at gmail.com Mon Jul 8 20:04:32 2013 From: lpsolit at gmail.com (=?windows-1252?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 08 Jul 2013 22:04:32 +0200 Subject: =?windows-1252?Q?It=92s_time_for_me_to_leave_the_B?= =?windows-1252?Q?ugzilla_project?= Message-ID: <51DB1B50.5010500@gmail.com> Hi all, As announced on my blog today [1], I resigned my role as assistant project lead for the Bugzilla project. The reasons are explained on my blog, see the link below. So please stop asking me for review. Patches already in my review queue will either be reviewed by me in the coming days or be moved into another reviewer's queue. If you have questions or requests about the future of Bugzilla, please ask justdave. My opinion is no longer the one you want to know. ;) It was a great experience to work with you guys, and I wish all the best for the future of Bugzilla! LpSolit [1] http://lpsolit.wordpress.com/2013/07/08/its-time-for-me-to-leave-the-bugzilla-project/ From justdave at bugzilla.org Tue Jul 9 19:50:40 2013 From: justdave at bugzilla.org (Dave Miller) Date: Tue, 09 Jul 2013 15:50:40 -0400 Subject: Where does the Bugzilla Project go from here? Message-ID: <51DC6990.1090302@bugzilla.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To Fr?d?ric: Thanks again for all your hard work over the years. As stretched as I?ve been for time myself it?s been a true godsend to have you picking up my slack the last few years. I'll have to be picking it up on my own now for a bit it seems. ;) To everyone else: For the time being, I'll be handling approval requests, so if you have something up for approval and it's not getting attention, I'm the one to pester. This is sort of the end of an era for the Bugzilla project... Both Max and Fr?d?ric have been with the project for much longer than most people every stick with a single employer in IT-related jobs (of which an open source project of this magnitude has a lot of similarities). For an open source project, that's outright amazing, as people tend to come and go a lot in most projects. It's kind of surprising that I've been around longer than them, but I'm kind of a "lifer" in some ways, and in reality I've had a good break from the project for the last few years because Max and Fr?d?ric have been mostly taking care of everything while I've been busy with other things. So it's time to begin a new era. Since I've had a good break to clear the monotony I'm going to be trying to get more involved myself again (which I've been saying every since Max left, but I have a lot more incentive now). I'd also like to kickstart a new team to lead the project. We have a number of positions within the project for various functions, which we've never really paid attention to as people moved on. I'd like to hold a project meeting (either on IRC or Google Hangouts or somesuch) in the very near future (a time and date will be announced soon) to discuss what of those positions in the project we still need, and who should be filling them. We also have some other "reinventing the project" type topics while we're at it. There's a number of things we've been talking about doing for a long time that we never really moved on, and when we're in the middle of big changes like this, I think it's a good time to attempt to tackle those again. The preliminary agenda has been posted at https://wiki.mozilla.org/Bugzilla:Meetings and I'll be nailing down a time and place and advertising it within the next couple days. - -- Dave Miller http://www.justdave.net/ IT Infrastructure Engineer, Mozilla http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFR3GmQ0YeDAOcbS44RApxTAJ4u4Z5VEZiP4G9ZcPFYdfSO3vlBPwCgpcdy 8GB/JV+pKvh2igcO09Lm92g= =Z6z3 -----END PGP SIGNATURE----- From harman.jay at gmail.com Wed Jul 10 19:44:37 2013 From: harman.jay at gmail.com (Jay Harman) Date: Wed, 10 Jul 2013 12:44:37 -0700 Subject: Self Introduction: Jay Harman Message-ID: Jay Harman JayHarman on IRC Portland, OR, USA Primarily a mathematics tutor. I'd like to help out with small bugs primarily - get to know the code before I work on anything huge. I did a lot of coding through high school and college, but haven't touched it in a few years. I'm looking to get back in the swing of things by helping out. I've taken a look at the "good for beginners" list of bugs, and I wanted to ask a couple of questions about bug 464688. Right now the code in Bugzilla::Object has a validate time function, which I could pretty easily modify to allow for time in HH:MM format, but I don't know where in the greater code that function is being called - Would it be better to accept that time as is or to convert it to decimal time? It would be a smaller patch if I just accept the HH:MM format, but if there are functions that take the time that has been validated and assume it's in the current format(possibly for calculating total time on a project or sorting bugs by time spent), that would lead to more bugs. Are there such functions? Thank you, Jay Harman -------------- next part -------------- An HTML attachment was scrubbed... URL: From kar at cray.com Wed Jul 10 20:22:32 2013 From: kar at cray.com (Kent Rogers) Date: Wed, 10 Jul 2013 15:22:32 -0500 Subject: Self Introduction: Jay Harman In-Reply-To: References: Message-ID: <20130710202230.GA23193@cray.com> Hi Jay, You need to get yourself a good source tree browser and/or learn to use 'find'. :-) The only places I can tell that Object::check_time() is called are in Comment.pm (to validate work_time) and Bug.pm (to validate estimated_time and remaining_time). Not sure what you mean by "accept that time as is", but I'm pretty sure you will need to convert the value to a decimal for processing in the Comment and/or Bug objects (see Bug::add_comment()). The time fields in the DB are decimals. -Kent On Wed, Jul 10, 2013 at 12:44:37PM -0700, Jay Harman wrote: > Jay Harman > JayHarman on IRC > Portland, OR, USA > Primarily a mathematics tutor. > I'd like to help out with small bugs primarily - get to know the code > before I work on anything huge. > I did a lot of coding through high school and college, but haven't touched > it in a few years. I'm looking to get back in the swing of things by > helping out. > > I've taken a look at the "good for beginners" list of bugs, and I wanted to > ask a couple of questions about bug 464688. Right now the code in > Bugzilla::Object has a validate time function, which I could pretty easily > modify to allow for time in HH:MM format, but I don't know where in the > greater code that function is being called - Would it be better to accept > that time as is or to convert it to decimal time? It would be a smaller > patch if I just accept the HH:MM format, but if there are functions that > take the time that has been validated and assume it's in the current > format(possibly for calculating total time on a project or sorting bugs by > time spent), that would lead to more bugs. Are there such functions? > > Thank you, > Jay Harman From glob at mozilla.com Mon Jul 1 07:36:43 2013 From: glob at mozilla.com (Byron Jones) Date: Mon, 01 Jul 2013 15:36:43 +0800 Subject: List of required packages? In-Reply-To: References: Message-ID: <51D1318B.4070909@mozilla.com> Gervase Markham wrote: > I'm sure somewher I've seen a list of packages you should apt-get > install when setting up Bugzilla on a new Ubuntu/Debian machine. It > seems like an obvious thing for our install docs to provide, but I can't > find it. Does it exist or am I imagining things? https://wiki.mozilla.org/Bugzilla:Prerequisites :) -- byron jones - :glob - bugzilla.mozilla.org team - _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Thu Jul 11 14:02:29 2013 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 11 Jul 2013 15:02:29 +0100 Subject: =?UTF-8?B?SXTigJlzIHRpbWUgZm9yIG1lIHRvIGxlYXZlIHRoZSBCdWd6aWw=?= =?UTF-8?B?bGEgcHJvamVjdA==?= In-Reply-To: <51DB1B50.5010500@gmail.com> References: <51DB1B50.5010500@gmail.com> Message-ID: <51DEBAF5.40904@mozilla.org> Hey Fr?d?ric, On 08/07/13 21:04, Fr?d?ric Buclin wrote: > As announced on my blog today [1], I resigned my role as assistant > project lead for the Bugzilla project. It's a sad day :-( Thank you very much for your awesome contributions; Bugzilla would not be nearly as good a piece of software as it is without your hard work. Gerv From Fred.Kleindenst at isilon.com Thu Jul 18 22:35:29 2013 From: Fred.Kleindenst at isilon.com (Kleindenst, Fred) Date: Thu, 18 Jul 2013 18:35:29 -0400 Subject: Work flow for checking out, branching from bugzilla trunk ... Message-ID: <776691157D89DE4AA026C5D990012C010252AC2B82@MX45A.corp.emc.com> Hello Devs, I'm looking for some sage advice on the best workflow for using source code control on several bugzilla bugs. Background ------------- I'm used to working with git. I have in dir a clone of the repo; and we are using a branch called "production" to be our HEAD. When I start work on a new bug, I make a new branch based on "production": Git checkout -b NewBranch This gives me (effectively) a fresh copy of "production" in a new workspace. I do some work, maybe a couple of commits, tests, etc. When I'm happy with everything, I switch back to "production": Git checkout production (make sure production is up to date) And then bring in my changes: Git merge "NewBranch" I can then push as needed to get things upstream to the live server. I'd like to do roughly the same with bzr and bugzilla. ------------------ I've gotten a copy to start with: Bzr checkout http://bzr.mozilla.org/bugzilla/trunk/ trunk Then made a copy work in Bzr branch trunk myNewBranch And got a diff out Bzr diff > myNewBranch.diff What would I do to "pull" other changes from Mozilla into trunk, then into myNewBranch? Any other tips for a good work flow? Fred Kleindenst EMC? | Isilon Storage Division Senior Tools Developer Office: 206.777.7887 Email: fred.kleindenst at isilon.com From 605507247 at qq.com Mon Jul 22 06:40:26 2013 From: 605507247 at qq.com (=?ISO-8859-1?B?amluZyA=?=) Date: Mon, 22 Jul 2013 14:40:26 +0800 Subject: Wide character in syswrite at /usr/lib/perl5/5.8.8/Net/Cmd.pm line 436.pm Message-ID: My os is Asiaunix , I install bugzilla4.4 on this pc, and I use mysql as my db. when I install I add "default-character-set=utf8" to /etc/my.cnf . And the status of utf8 on params seting pages is default to on. Then I can submit or change status of bugs successfully when they are written in english . But when I use chinese to describe the bug , the massage "soft error :Wide character in syswrite at /usr/lib/perl5/5.8.8/Net/Cmd.pm line 436.pm" will show . And the email can't be sent. I had seen the bug recode in Bug List . And I dropped the database, re-ran checksetup.pl and recode.pl. . but still doesn't work. So I don't know what to do . And how can aviod to this problem when I install bugzilla on other pc? Or which version of bugzilla can I use without this problem? Please help.Thank you vsery much . _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From Fred.Kleindenst at isilon.com Mon Jul 22 19:28:31 2013 From: Fred.Kleindenst at isilon.com (Kleindenst, Fred) Date: Mon, 22 Jul 2013 15:28:31 -0400 Subject: How do I go about assign a bug to myself ? Message-ID: <776691157D89DE4AA026C5D990012C010252AC2D94@MX45A.corp.emc.com> For example, this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=287332 The link in the UI in an emailto: I fired off a message there, but did not receive a reply. Cheers --Fred Fred Kleindenst EMC? | Isilon Storage Division Senior Tools Developer Office: 206.777.7887 Email: fred.kleindenst at isilon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Mon Jul 22 19:35:42 2013 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 22 Jul 2013 21:35:42 +0200 Subject: How do I go about assign a bug to myself ? In-Reply-To: <776691157D89DE4AA026C5D990012C010252AC2D94@MX45A.corp.emc.com> References: <776691157D89DE4AA026C5D990012C010252AC2D94@MX45A.corp.emc.com> Message-ID: <51ED898E.5040303@gmail.com> Le 22. 07. 13 21:28, Kleindenst, Fred a ?crit : > The link in the UI in an emailto: I fired off a message there, but did not receive a reply. Don't be so impatient. :) You attached your patch only a few days ago. Give reviewers some time to look at your patch. Depending on how busy they are, it can take a few weeks. In that case, better is to jump into the #bugzilla IRC channel and pester them directly. :) About assigning the bug to you, they will do it once they start looking at your patch. LpSolit From mtb19 at columbia.edu Tue Jul 23 21:03:22 2013 From: mtb19 at columbia.edu (Matthew Bogosian) Date: Tue, 23 Jul 2013 14:03:22 -0700 Subject: BugzilLi0n - Summary of Problem & Suggested Approaches [INCOMPLETE] Message-ID: Apologies for the cross posting. I'm not sure exactly where this discussion should take place (I think developers@, but I'm Cc'ing localizers@ just in case). Below is my assessment on the linguistic adaptation problem and the state of Bugzilla's solution(s) to that problem. I have included recommendations for future action, but that is secondary. The assessment below is primarily to solicit comment and encourage discussion in order to establish a clear direction for any sustained effort in this area. WARNING: This is INCOMPLETE. I had originally planned on dedicating more time to this effort, but life happens, and I am no longer able to. However, I did not want my research to go to waste. I hope this will be useful to someone who comes in after me. --Matt (IRC: posita) BACKGROUND & INTRODUCTION About a year ago, somewhat by accident, I started looking into the state of the internationalization and localization world for Bugzilla (i.e., i18n, l10n, l20n, which I will collectively call "BugzilLi0n"*). I started off with (what I thought was) a simple experiment: I wanted to see if I could adapt a local Bugzilla installation to serve as a law firm issue tracker and work flow manager. (Footnote *: Pronounced, "bug-ZIL-ee-yun", or "bug-zih-LO-kah-lih-ZAY-shun".) Lawyers and paralegals are notoriously slow to adopt new technology. Technological offerings in that field are not only clunky and often well behind the feature curve, but they are almost always offensively expensive. Having spent about a decade in software development, but finding myself now working in a different field, I longed for familiar tools and features I knew would be immediately useful in my new context (even with minimal training of others). I settled on an approach: take a stable release of Bugzilla and see if I could adapt it to a relatively foreign environment through template editing, perhaps some extensions, but with with minimal patching. It occurred to me that some of the difficulties I was experiencing were broader than my narrow goals, so I decided to investigate further. I quickly and necessarily encountered some of the localization issues that garnered much discussion about 4-5 years ago. It didn't seem like much more work to consider solutions that, in addition to serving my own narrow goals, could be reusable in a broader context which led me to participate in this forum. Disclaimer These comments and observations are mine alone. They are the result of only a handful of hours of investigation as an outsider with specific goals (i.e., biases). They should be afforded appropriate skepticism. Also, I am not an expert in linguistics. English is my native language. I learned French in high school (and have forgotten most of it). I speak enough Spanish to awkwardly order a cup of coffee and that's about it. Some of the material presented herein will be remedial or obvious to participants, but I thought a comprehensive summary would be useful for onlookers. Please note that I do not address the concept of automatic language selection or "fallback". That is a problem I consider related to, but separate from this discussion. WHERE IS BUGZILLIi0N TODAY? (I believe) I have looked through most of the materials relating to the problem of adaption. The Bugzilla universe appears largely unchanged from around 2008-9-ish with some tapering off in 2010. However, other Mozilla projects have maintained various discussions (see, e.g., , , , etc.). Bugzilla currently delegates nearly all of its language adaptation to templates which are parsed and processed by Template Toolkit with Bugzilla-specific extensions. I say "nearly" because there are situations (e.g., custom fields, , etc.) where display values can come straight from non-template sources which are not currently localized (see also ). There are probably work-arounds for use cases employing custom fields concurrently with support for different languages, but those work-arounds likely require a level of technical expertise not available to most (e.g., Perl, an understanding of Bugzilla's Template Toolkit, Bugzilla Perl APIs, etc.) and a level of hacking ugliness which would likely frustrate attempts to upgrade by patch. PROBLEM IN TWO PARTS Is Bugzilla currently as adaptable as it "needs" to be? This is currently unclear to me. To understand my discussion on this topic, it may help to review and to understand the types of contextual linguistic nuances present in languages other than English that might benefit accommodation. In my assessment, the difficulties Bugzilla is experiencing with localization stem in part from the fact that the product is (or at least was initially) developed primarily by English speakers (so it has a natural bias toward solving linguistic problems in that domain), and in part from the fact that English has relatively simple rules respecting plurality, gender, formality, etc. I have yet to find a counterexample**, but for the most part, the problem of localization within a UI can be modeled with the following distinct(ish) but related layers: Query Display Logic v (Context Data) v Linguistic Logic Response Display Logic ^ (Compliant Text) ^ Linguistic Logic (Footnote **: Except perhaps that of Japanese, where displaying the same data in the same layout may require different language depending on the status of the viewer [e.g., worker bee, boss, customer, etc.], although in a broad sense, the presented model could accommodate such situations with appropriately rich context data. See, e.g., .) "Display logic" can be thought of as providing structure to the display of contextually relevant data. For seeing users***, this largely involves laying out the parts or subparts of a page or screen (e.g., a tabular format for a report, field name/value pairs for attributes, a linear list of comments as part of a discussion, input for performing a search, etc.). (Footnote ***: Alternatively accessible formats are beyond the scope of this discussion, but useful to keep in the back of one's mind.) Part of the larger responsibility of the display logic layer is to display blocks of written language (text) within those subparts. However, language has its own rules (which I've labeled as "language logic"). In order to apply those linguistic rules correctly, context data must be provided. It is possible this context is appropriately discovered and communicated by the display logic layer, but this is not necessarily a requirement (it could come from somewhere else). This is easier to model in broad theory than apply in practice. Assuming one could discover the number and genders of an audience, consider the following (contrived) example where one wants to display a status string above a list of query results: "As of [date/time], there were [#] result[s] to your query, [sir/ma'am/gentlemen/ladies/lady and gentlemen/ladies and gentleman/ladies and gentlemen]." Date and time formatting is a fairly common and well-understood aspect of localization. Despite this, the layer to be responsible for formatting isn't always clearly delineated. Static string libraries are ill-suited to formatting dynamic data, so this often gets done in the display logic layer. Additionally, the display logic layer may not care about the specific number of results from a query. It might be perfectly happy just iterating through a list of zero or more items to present the contents of zero or more rows in a table. But, in order for the linguistic layer to do its job, metadata about the query results needs to be gathered or computed (i.e., a count). In addition, number and gender of the audience is likely irrelevant to the layout, but is very relevant to the linguistic layer. There are two messy solutions: either provide everything to the linguistic logic layer, and let that layer figure it out, or figure out what is needed by the linguistic layer and provide only that. In the first case, the linguistic layer is no longer purely linguistic. It needs to know fairly detailed information about the data it receives in order to make sense of it. In the second case, the display logic layer needs to know fairly detailed information about what is needed by all potential instances of the linguistic layer. I say "all" because some information may be needed by some linguistic contexts, but ignored by others. The display logic layer would likely need to provide all data potentially needed by all linguistic contexts if it wanted to avoid being in the business of figuring out which went with which. A controller implementation may be an appropriate intermediary, but the work needs to be done somewhere. There Is No Free Lunch. Currently, Bugzilla attacks this problem by munging the two layers inside the template. As I alluded to above, I believe the current implementation is likely sufficient to afford solutions to most localization issues. However, there are several drawbacks. First, there is little reuse because reuse is either hard or ugly. Templates are already difficult to create/maintain.**** One really needs to understand the Bugzilla-specific oddities like Template Toolkit parsing extensions, field_descs, global/variables.none.tmpl, etc., and one should probably know Perl. This shrinks the market of potential new maintainers considerably. By the way, I don't think this is specific to Bugzilla. Many architectures, including Google Apps (Django) necessitate significant coordination between display logic and linguistic logic layers, etc. It's a Hard Problem. (Footnote ****: Please understand, I am not talking about existing maintainers, although their pain is of concern as well. I'm talking about making it easier for outsiders to adapt Bugzilla to new linguistic contexts. The barrier to entry is high, even if it is documented [see ]. There is, of course, a risk that even with the requisite expertise, existing maintainers will give up if modifications are too difficult. This should be avoided, as loss of expertise is very costly.) Without a clearly effective way to separate and easily maintain the above-identified layers, I am reluctant to recommend changing the current implementation, simply because the problem is significant. Effort should be proportionate to realized gain. One needs to be careful where significant work is likely, but where the magnitude of any benefit is unclear, and where implementation of one solution may be difficult to leverage if another solution is adopted later. I will attempt to address this in the next section. If Bugzilla needs increased adaptability, what are the viable solutions? INCOMPLETE. This section needs more work and more details. There are tools out there like Locale::Maketext and perllocale, but their use likely requires a lot of care and thought or one will just end up with a spaghetti mess. I do not know this to be true, but Bugzilla's current template set feels like it evolved organically (kind of like a scrappy patchwork class hierarchy) where contributors came and went and abstracted where it was immediately convenient to add features or fix bugs without too much thought about overarching conventions. Please note, I mean no offense by that observation. It is normal (and perhaps healthy). For example, I suspect where several pages need to display a table list of bugs, that table list was pulled out and referenced by the pages on which it appears. Subtle (and not so subtle) differences were parameterized as needed by the client pages. Feature requests came in, and the table list was further parameterized. Ultimately, these kinds of extract-and-reference bits become hyper-specific to their own tasks. Basically, any recommendation likely comes down to: 1) continue collapsing the display/language layers inside of things like templates and leave the hard work to the template maintainers; or 2) try to separate them out knowing that calling layers are going to need to provide a lot of language-specific data to the language layer. Regarding option 1, see (metaphorically) Networking Truth # 5. It also has the effect of potentially alienating extension writers who have to patch templates to inject display material where they need it. This sucks, but it seems to have been the de facto convention for quite some time, so who am I to judge? Regarding option 2, it might be cleaner, but only if it can provide clear and (perhaps more importantly) consistent interfaces (contracts) to (e.g.) the display layer. There are probably a small number of contextual types (e.g., counts, gender/count pairs, date/time, money, etc.), but someone would likely need to invest a lot of time designing and experimenting with those interfaces to avoid just making things messier. See Networking Truths #s 6 and 6a. See also: CONCLUSION - TWO PATHS EXIST, BUT EACH HAS TRADE-OFFS In short, it's either: 1) more of the same; or 2) adoption of a new approach once the benefits of that path can be identified and are proportionate to the effort required for integration. My own knowledge (and bandwidth) is limited, so guidance is required. In the absence of a clear winner, my guess is option 1 is "good enough" for right now, unless someone is really passionate about experimenting with option 2. Hopefully localization is sexy enough to attract a champion. I hope this assessment has been useful, if only to remind existing stakeholders of the specifics of the issues. REFERENCE MATERIAL Bugs Secondary Materials Related Technologies Kittens (Because Who Doesn't Love Kittens?!) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4237 bytes Desc: not available URL: From cedric.corazza at wanadoo.fr Tue Jul 23 22:39:18 2013 From: cedric.corazza at wanadoo.fr (=?windows-1252?Q?C=E9dric_Corazza?=) Date: Wed, 24 Jul 2013 00:39:18 +0200 Subject: BugzilLi0n - Summary of Problem & Suggested Approaches [INCOMPLETE] In-Reply-To: References: Message-ID: <51EF0616.5080902@wanadoo.fr> Le 23/07/2013 23:03, Matthew Bogosian a ?crit : > Apologies for the cross posting. I'm not sure exactly where this > discussion should take place (I think developers@, but I'm Cc'ing > localizers@ just in case). [?] Hi, I've been the French localizer of Bugzilla for some time now. I remember we had a discussion about making easier the Bugzilla localization (I couldn't find it right now). The proposed solution was painful for both developers and localizers. This is probably due to the intrinsic nature of template toolkit (and Perl) and by the fact that, in the early beginning, Bugzilla was an internal tool for Mozilla usage. And even when Mozilla products had to be localized, the localizers using Bugzilla were supposed to speak English. All the work done on Bugzilla codebase along these years and the Bugzilla users base (I'm thinking about RedHat or Yahoo installations, which are part of the biggest Bugzilla databases) make it difficult to modify the code logic as, as far as I know, most Bugzilla installations are en-US. I should have been contacted by 5 or so people since I've been localizing Bugzilla, to fix the French templates (I don't know the involved userbase). My two cents. Regards C?dric