Mark Mentovai <mark@moxienet.com> has denied Smokey Ardisson (no bugmail - =
do
not email) <alqahira@ardisson.org>'s request for superreview:
Bug 392918: Convert all .strings files to UTF-8 for diff-friendliness and i=
conv
them to UTF-16 during build
https://bugzilla.mozilla.org/show_bug.cgi?id=3D392918
Attachment 284885: trunk patch
https://bugzilla.mozilla.org/attachment.cgi?id=3D284885&action=3Dedit
------- Additional Comments from Mark Mentovai <mark@moxienet.com>
In the Makefile:=0D
=0D
When you find yourself writing the same thing over and over again, there's
probably a better solution. In this case, we can add a fragment of this fo=
rm
to the Makefile:=0D
=0D
STRINGS_FILES =3D x.strings y.strings z/z.strings=0D
GENERATED_STRINGS_FILES =3D $(patsubst %,generated/%,$(STRINGSFILES))=0D
=0D
$(GENERATED_STRINGS_FILES): generated/%.strings: $(srcdir)/%.strings.in
generated=0D
mkdir -p $(dir $@)=0D
iconv -f UTF-8 -t UTF-16 $< > $@=0D
=0D
GENERATED_STRINGS_FILES expands to include generated/x.strings,
generated/y.strings, and generated/z/z.strings. The rule to build those has
been made generic. The substitution form of the prerequisites says that to
build, for example, generated/z/z.strings (which becomes $@), use
z/z.strings.in (which becomes $<). We do the mkdir directly here (in addit=
ion
to relying on generated, which is now optional) because we need something to
create arbitrary directories, like generated/z.=0D
=0D
This also helps out your libs:: line, to answer your question, because all =
of
the stuff you need is in $(GENERATED_STRINGS_FILES). You need only add
$(GENERATED_STRINGS_FILES) to your libs:: line. Also, with the double-colon
variety, you can have multiple libs:: lines, each specifying different
prerequisites.=0D
=0D
What I've given you here will require a minor reworking of the paths in your
patch (or some tweaking to what I've offered - the tweaking, frankly, is
probably excessive, so it's probably easier to just change the paths.) As an
example, your patch used
PreferencePanes/Downloads/English.lproj/Localizable.strings.in to build
generated/Downloads/English.lproj/Localizable.strings. With my patch, you'll
instead build
generated/PreferencePanes/Downloads/English.lproj/Localizable.strings. Note
the presence of generated/PreferencePanes. No biggie.=0D
=0D
Since this pretty much requires us to have a full "shadow" directory struct=
ure
in generated, we should move generated/English.lproj/InfoPlist.strings to
generated/resources/localized/English.lproj/InfoPlist.strings, too. See wh=
at
I'm saying? You can whack the generated/English.lproj rule as a result, and
move InfoPlist.strings to use the mkdir pattern from above for convenience =
and
parity.=0D
=0D
Looking in the project file at .strings files not named Localizable.strings:
CertificateDialogs.strings is named English in the project, but
RegionNames.strings has its own name. Intentional?=0D
=0D
Nits in the existing strings files: CertificateDialogs.strings.in has a lea=
ding
newline, whack it. The tabs in RegionNames.strings.in look awful.=