516640 - Fully automate generation of localizable Cocoa .strings files for Gecko .properties files during the build

Status: RESOLVED WONTFIX

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

In the middle of bug 394105, we described a process by which Cocoa .strings files could be generated from Gecko .properties files.  Due to time and build-engineer-knowledge constraints, we ended up only implementing part of the process, which simply took manually generated foo_properties.strings.in files and converted them to UTF-16 foo_properties.strings files.

See bug 394105 comment 18 for the overview of the process and bug 394105 comment 17-21 (and a bit of bug 394105 comment 24) for more details.

(In reply to bug 394105 comment #18)
> Just for reference/the record, below is a skeleton for automating the
> extraction part.  There are two issues with it yet: doing the renames
> correctly, and reworking the Makefile's libs:: target so that the
> $(GENERATED_GECKO_STRINGS_FILES) target gets run after the embed-replacements
> rsync (so that we have the latest/correct files).  If we get extraction
> automated, we may want to rework the $(GENERATED_GECKO_STRINGS_FILES) target
> anyway and just work on an auto-generated list of files or something, rather
> than doing the substitution stuff.
> 
> mkdir -p strings-tmp
> cd strings-tmp
> unzip -ou ../../dist/Embed/chrome/embed.jar -d .
> find . -name "*.properties"
> cp locale/en-US/communicator/*.properties \
>                   communicator_locale_*_properties.strings.in
>                 global/*.properties \
>                   global_locale_*_properties.strings.in
>                 global/dom/*.properties    \
>                   global_locale_dom_*_properties.strings.in
>                 global/layout/*.properties \
>                   global_locale_layout_*_properties.strings.in
>                 global/security/*.properties \
>                   global_locale_security_*_properties.strings.in
>                 global-platform/*.properties \
>                   global-platform_locale_*_properties.strings.in
>                 global-region/*.properties \
>                   global-region_locale_*_properties.strings.in
>                 necko/*.properties \
>                   necko_locale_*_properties.strings.in
>                 pipnss/*.properties \
>                   pipnss_locale_*_properties.strings.in
>     (pax might be able to do this, or perl or ruby; I used AS)
> cp *.strings.in resources/localized/English.lproj/gecko
> (Add strings-tmp to GARBAGE_DIRS)
> (Rework Makefile.in libs:: rule to get things called in the correct order)

Also, for posterity, the corrected Makefile hunk for manual escaping/transformation (see bug 394105 comment 19 and patch in bug 394105 comment 17) appears to have been: 

> sed -E -e "s/^#(.*)$$/\/\* #\1 \*\//" \
>        -e 's/\"/\\\"/g' \
>     -E -e "s/^([^\"#= ]*)([[:space:]]*)=([[:space:]]*)(.*)$$/\"\1\" = \"\4\";/" $< | \
> iconv -f UTF-8 -t UTF-16 > $@ 

I can't guarantee this is correct since it was never part of a tested Makefile patch, but all my notes seem to indicate that was what I developed before switching to manually transforming the files via TextWrangler, whose regexps have a slightly different syntax.

Comment 1

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]