Closed Bug 257533 Opened 20 years ago Closed 20 years ago

getting de-DE to work right for Firefox 1.0PR

Categories

(Mozilla Localizations :: de / German, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: MMx, Assigned: atopal)

Details

In this bug, I want to collect all bugs that currently exist in the de-DE
translation for Firefox, and find possible issues in the Firefox build system
that have to be resolved as well.


The first thing to start with is:
in my "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-DE; rv:1.7.3)
Gecko/20040831 Firefox/0.9.2 (MMx)", the "about:" page and the about-dialog
shows "Firefox @APP_VERSION@"

bsmedberg said to this issue in #developer:
"13:25 < bsmedberg> MMx/Pike: browser/chrome/global/brand.dtd needs #filter
substitution"

lets see what else we can find ;)
regarding browser/de-DE/includes.inc bsmedberg found that it lacks # before
the defines, and that the one "we" have in a 7zip has line ending issues, too.
The line-endings shouldn't be a problem. CVS will take care of them while 
uploading. And Ý removed the #'s because i thought it was neccessary in order 
to process them (there is no documentation at all and another undefinded thing 
is the id at the beginning of the file. is it a GUID? Do we need to use 
different ID's for every release or one single ID per locale?) Anyway: I can 
add the #'s and convert the file if needed, but what I would really like to 
know: Does this locale build?
Status: NEW → ASSIGNED
> is the id at the beginning of the file. is it a GUID? Do we need to use 
> different ID's for every release or one single ID per locale?) Anyway: I can 

It is a GUID, it is the "extension ID" used for the langpack XPI. It should be
the same for each release (and different from English, of course).

> add the #'s and convert the file if needed, but what I would really like to 
> know: Does this locale build?

Yes, when I added the # back and made all the line endings unix-style in
defines.inc, it builds and the unix installer builds.
(In reply to comment #2)
<snip>
> but what I would really like to know: Does this locale build?

As you might have guessed from my comment #c0:
It does build fine on MacOS. :)
So, I just checked in the changes AT mailed me. cvs check in comment was

changing german (de-DE) localisation to reflect string changes due to bugs
249231,85420,251092,255932,238571,254439,253046,255113,174854,253046,232399,256932,253332
and 254175, new searchengines added per bug 242586 and a change to intl.css to
get a proper size for lokalised pref-advancedscripts, checking in for a.topal

AT's files had license plates, which were too far off, IMHO, so I nuked them.
More details on that in private mail.
That led to a whole bunch of files that didn't get modified other than the 
changelog of MT, which I didn't check in.

Because I'm shupid, I had to convert the line endings to unix in the rep, too.
Everything should be fine for all platforms now.

The current state builds, but it comes up with an xmlparse error for the
great update overhaul.

I fixed both issues from #0, too.
got the new package from A.Topal today and found fresh issues:

in toolkit/chrome/global:
1.  error: file './de-DE/chrome/global/license.dtd' doesn't exist at
../../config/make-jars.pl line 418.
2.  also mozilla.dtd in the same directory.

in browser/chrome/browser:
3.  error: file './de-DE/chrome/browser/searchbar.properties' doesn't exist at
../../config/make-jars.pl line 418
4.  aboutDialog.dtd has to be changed.
5.  browser.properties and browser.dtd newer modification dates in en-US
6.  in browser.dtd "<!ENTITY updatesItem.title "Updates">" is missing

7.  browser/content/pref/pref-advanced.xul: "<checkbox
id="loadBookmarksInBackground" ...>

8.  mozapps/content/extensions/extensions.xul: &cmd.options.tooltip;

there are probably others, but these are what I found so far.
People with access to a Mac can test the build if they want: 
http://firefox.kicks-ass.org/download/unofficial/nightly/AVIARY_BRANCH/FirefoxMacOSX_AVIARY_deDE.2004-09-13.dmg.bz2
(I worked around/fixed errors 1-6 in this build)
Another bug (259425) has a similar problem with fr-FR. The problem is a
corrupted chrome.rdf file. Making a new profile will fix this.
Thanks, but in our case the problem was, that I mixed up the files I sent
earlier with the new ones. Everything should be okay now.
Now that the tinderbox is green I suggest this is fixed. All remaining problems
are of a more global scale and dealed with in other bugs.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.