superreview denied: [Bug 392918] Convert all . strings files to UTF-8 for diff-friendliness and iconv them to UTF-16 during build

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.=
0
bugzilla
10/15/2007 5:29:07 PM
mozilla.dev.super-review 29307 articles. 3 followers. Post Follow

0 Replies
559 Views

Similar Articles

[PageSpeed] 8
Get it on Google Play
Get it on Apple App Store

Reply: