[slides.git] / fosdem2004 / l10ntalk_02.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">
  <meta name="Author" content="KaiRo - Robert Kaiser">
  <title>L10n talk - FOSDEM 2004 - Mozilla Meeting</title>
  <link rel="stylesheet" type="text/css" href="l10ntalk.css">
  <link rel="contents" href="index.html" title="Contents">
  <link rel="index" href="l10ntalk_overview.html" title="Overview">
  <link rel="glossary" href="l10ntalk_glossary.html" title="Glossary">
  <link rel="start" href="index.html" title="Start">
  <link rel="first" href="l10ntalk_01.html" title="First page">
  <link rel="previous" href="l10ntalk_01.html" title="Previous page">
  <link rel="next" href="l10ntalk_03.html" title="Next page">
  <link rel="last" href="l10ntalk_end.html" title="Last page">
</head>
<body>

<h1>diff -D 02/2003 -D 02/2004 mozilla-l10n</h1>

<div class="explanation">
<pre>--- mozilla-l10n        2003-02-FOSDEM
+++ mozilla-l10n        2004-02-FOSDEM
@@ -a,b +x,y @@</pre>
Well, let's make it a small bit less geeky ;-). So what has happened in the last year of Mozilla L10n?
<ul>
 <li class="minus"><b>big manual localeVersion change patches</b>: locale packs from different Mozilla versions are incompatible because of
     changed, added or removed texts in the UI. To avoid crashes or other side-effects, we have internal
     versioning of locale in chrome registry, fed into it by contents.rdf files.
     <br>Those were <span class="hilite">previously hardcoded</span> and I did big manual patches to change them. After I found a way to 
     insert the versions at build-time and patched the whole tree to do that using the C preprocessor
     (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=154927" title="automate localeVersion updates based on milestone.txt">bug 154927</a>),
     I was told we should use the <span class="hilite">XUL preprocessor</span>. I made that change recently
     (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=232011" title="Use the XUL preprocessor for build-time inserting of localeVersion strings">bug 232011</a>)
     and set tinderboxen on fire (as some of you may remember)...
     <br>After some help from tinderbox admins and bsmedberg (who had to fix make-jars.pl for a bug I triggered),
     we should now have that long-standing bug finally resolved (and themes will follow that way soon -
     <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=234014" title="Use the XUL preprocessor for build-time inserting of skinVersion strings">bug 234014</a>).
     <br>BTW, all chrome version strings are now defined in
     <a href="http://lxr.mozilla.org/mozilla/source/config/chrome-versions.sh">mozilla/config/chrome-versions.sh</a>.</li>
 <li class="minus"><b>XPI error -239</b>: When installing our <span class="hilite">locale XPI files</span>, we often ran into XPInstall
     error -239 (CHROME_REGISTRY_ERROR), especially on unix machines. This had been happening quite
     frequently for at least 18 months
     (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=109044" title=" 	Install error -239 registering chrome on some systems">bug 109044</a>),
     and noone had an idea why that happened, when it started magically disappearing in some cases last summer.
     <br>DocWilco then <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=109044#c64">filed a patch</a>
     for a case where he was still seeing (and which was "a tough one to crack"), and we didn't hear a lot about
     that error again. He also <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=221994">improved reporting</a>
     of what happens when it still hits a -239 in a followup.
     <br>Another nasty <span class="hilite">problem is history now</span>.</li>
 <li class="plus"><b>more attention to L10n</b>: Starting with last December, L10n got more attention of
     mozilla.org staff than in previous times. It all started with a staff meeting on 2003-12-08 (see the
     <a href="http://groups.google.com/groups?as_umsgid=3FDB8346.9010004@mozilla.org">"minutes" posting</a>):
     <pre class="border">
     *Localisation packs*

- Quarterly/monthly <span class="hilite">IRC meetings</span> for l10n (blizzard, bart)
- What is our end goal for internationalization?
- <span class="hilite">Goal: 5 or 6 languages we ship pretty regularly</span>, of reasonable to good
   quality
- Start incrementally

- Agreed: <span class="hilite">translations need to be in CVS</span>; too separated from release
   process

- chofmann to write a message to l10n newsgroup:
   - 1) Tell people how to nominate bugs to drivers
   - 2) Mention monthly IRC chat, hosted by chofmann
        (gerv query: what time to have this? Hard to pick one which is
         good for everyone, because of timezone issues)
   - 3) If you have a localised version ready 1 week after 1.6, let us
        know now (or then) and we'll try and get it on the CD.
   - 4) There will be a <span class="hilite">string freeze after beta</span> - it's a done deal
   - 5) We want your localisation by 1 week after our planned release
        date (But CD gets burned 2 days before we release)

- We need a simple post-freeze string change process - Bugzilla keyword,
   post to newsgroup etc.</pre>
   The first L10n IRC meeting was on 2003-12-15, The 1.6 CD shipped with a few important / finished-in-time
   localization XPI packs, we're still hoping further actions will happen. The first string freeze (1.7b -> 1.7)
   is still to happen, and getting translations into CVS is actually a quite old bug report,
   <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=57878" title="Translations should be in CVS">bug 57878</a>,
   that still doesn't have much attention, as well as the one for
   getting German L10n into CVS
   (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=179949" title="Get German/de-AT translation into CVS">bug 179949</a>).
   <br>Let's hope the positive movement of December can be carried on into the future.</li>
 <li class="plus"><b>Mozilla Europe</b>: Just last week, the <a href="http://www.mozilla-europe.org/">Mozilla Foundation Europe</a>
   has been launched, having a <span class="hilite">multi-language web site</span>, and that probably will
   <span class="hilite">attract even more users</span> to localized versions of Mozilla and its derivates.
   <br>We'll see what this means to our L10n projects...</li>
</ul>
</div>

<p class="forward"><a href="l10ntalk_03.html">next</a></p>

</body>
</html>
Commit	Line	Data
3288eeda	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
	2	<html>
	3	<head>
	4	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">
	5	<meta name="Author" content="KaiRo - Robert Kaiser">
	6	<title>L10n talk - FOSDEM 2004 - Mozilla Meeting</title>
	7	<link rel="stylesheet" type="text/css" href="l10ntalk.css">
	8	<link rel="contents" href="index.html" title="Contents">
	9	<link rel="index" href="l10ntalk_overview.html" title="Overview">
	10	<link rel="glossary" href="l10ntalk_glossary.html" title="Glossary">
	11	<link rel="start" href="index.html" title="Start">
	12	<link rel="first" href="l10ntalk_01.html" title="First page">
	13	<link rel="previous" href="l10ntalk_01.html" title="Previous page">
	14	<link rel="next" href="l10ntalk_03.html" title="Next page">
	15	<link rel="last" href="l10ntalk_end.html" title="Last page">
	16	</head>
	17	<body>
	18
	19	<h1>diff -D 02/2003 -D 02/2004 mozilla-l10n</h1>
	20
	21	<div class="explanation">
	22	<pre>--- mozilla-l10n 2003-02-FOSDEM
	23	+++ mozilla-l10n 2004-02-FOSDEM
	24	@@ -a,b +x,y @@</pre>
	25	Well, let's make it a small bit less geeky ;-). So what has happened in the last year of Mozilla L10n?
	26	<ul>
	27	<li class="minus"><b>big manual localeVersion change patches</b>: locale packs from different Mozilla versions are incompatible because of
	28	changed, added or removed texts in the UI. To avoid crashes or other side-effects, we have internal
	29	versioning of locale in chrome registry, fed into it by contents.rdf files.
	30	<br>Those were <span class="hilite">previously hardcoded</span> and I did big manual patches to change them. After I found a way to
	31	insert the versions at build-time and patched the whole tree to do that using the C preprocessor
c9fb8495	32	(<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=154927" title="automate localeVersion updates based on milestone.txt">bug 154927</a>),
3288eeda	33	I was told we should use the <span class="hilite">XUL preprocessor</span>. I made that change recently
c9fb8495	34	(<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=232011" title="Use the XUL preprocessor for build-time inserting of localeVersion strings">bug 232011</a>)
3288eeda	35	and set tinderboxen on fire (as some of you may remember)...
3288eeda	36	<br>After some help from tinderbox admins and bsmedberg (who had to fix make-jars.pl for a bug I triggered),
0437d853	37	we should now have that long-standing bug finally resolved (and themes will follow that way soon -
c9fb8495	38	<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=234014" title="Use the XUL preprocessor for build-time inserting of skinVersion strings">bug 234014</a>).
3288eeda	39	<br>BTW, all chrome version strings are now defined in
	40	<a href="http://lxr.mozilla.org/mozilla/source/config/chrome-versions.sh">mozilla/config/chrome-versions.sh</a>.</li>
	41	<li class="minus"><b>XPI error -239</b>: When installing our <span class="hilite">locale XPI files</span>, we often ran into XPInstall
	42	error -239 (CHROME_REGISTRY_ERROR), especially on unix machines. This had been happening quite
c9fb8495	43	frequently for at least 18 months
c9fb8495	44	(<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=109044" title=" Install error -239 registering chrome on some systems">bug 109044</a>),
3288eeda	45	and noone had an idea why that happened, when it started magically disappearing in some cases last summer.
	46	<br>DocWilco then <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=109044#c64">filed a patch</a>
	47	for a case where he was still seeing (and which was "a tough one to crack"), and we didn't hear a lot about
	48	that error again. He also <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=221994">improved reporting</a>
	49	of what happens when it still hits a -239 in a followup.
	50	<br>Another nasty <span class="hilite">problem is history now</span>.</li>
	51	<li class="plus"><b>more attention to L10n</b>: Starting with last December, L10n got more attention of
	52	mozilla.org staff than in previous times. It all started with a staff meeting on 2003-12-08 (see the
	53	<a href="http://groups.google.com/groups?as_umsgid=3FDB8346.9010004@mozilla.org">"minutes" posting</a>):
	54	<pre class="border">
	55	Localisation packs
	56
	57	- Quarterly/monthly <span class="hilite">IRC meetings</span> for l10n (blizzard, bart)
	58	- What is our end goal for internationalization?
	59	- <span class="hilite">Goal: 5 or 6 languages we ship pretty regularly</span>, of reasonable to good
	60	quality
	61	- Start incrementally
	62
	63	- Agreed: <span class="hilite">translations need to be in CVS</span>; too separated from release
	64	process
	65
	66	- chofmann to write a message to l10n newsgroup:
	67	- 1) Tell people how to nominate bugs to drivers
	68	- 2) Mention monthly IRC chat, hosted by chofmann
	69	(gerv query: what time to have this? Hard to pick one which is
	70	good for everyone, because of timezone issues)
	71	- 3) If you have a localised version ready 1 week after 1.6, let us
	72	know now (or then) and we'll try and get it on the CD.
	73	- 4) There will be a <span class="hilite">string freeze after beta</span> - it's a done deal
	74	- 5) We want your localisation by 1 week after our planned release
	75	date (But CD gets burned 2 days before we release)
	76
	77	- We need a simple post-freeze string change process - Bugzilla keyword,
	78	post to newsgroup etc.</pre>
	79	The first L10n IRC meeting was on 2003-12-15, The 1.6 CD shipped with a few important / finished-in-time
	80	localization XPI packs, we're still hoping further actions will happen. The first string freeze (1.7b -> 1.7)
	81	is still to happen, and getting translations into CVS is actually a quite old bug report,
c9fb8495	82	<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=57878" title="Translations should be in CVS">bug 57878</a>,
	83	that still doesn't have much attention, as well as the one for
	84	getting German L10n into CVS
	85	(<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=179949" title="Get German/de-AT translation into CVS">bug 179949</a>).
3288eeda	86	<br>Let's hope the positive movement of December can be carried on into the future.</li>
	87	<li class="plus"><b>Mozilla Europe</b>: Just last week, the <a href="http://www.mozilla-europe.org/">Mozilla Foundation Europe</a>
	88	has been launched, having a <span class="hilite">multi-language web site</span>, and that probably will
	89	<span class="hilite">attract even more users</span> to localized versions of Mozilla and its derivates.
	90	<br>We'll see what this means to our L10n projects...</li>
	91	</ul>
	92	</div>
	93
0437d853	94	<p class="forward"><a href="l10ntalk_03.html">next</a></p>
0437d853	95
3288eeda	96	</body>
3288eeda	97	</html>