[wp-polyglots] Locale Directory Structure

[K Suominen]

On Sun, 27 Feb 2005 23:03:42 -0800, Morgan Doocy <morgan at doocy.net> wrote:
> On Feb 27, 2005, at 10:25 PM, Ryan Boren wrote:
> > On Mon, 2005-02-28 at 00:07 -0500, K Suominen wrote:
> >> The fi_FI locale currently already has fully automated packaging
> >> implemented.  It can also be easily extended to cover more locales, by
> >> calling make(1) recursively, e.g. from an upper-level directory.
> >
> > That's good, although I hesitate to ask people to maintain Makefiles.
> > One simple script could handle the packaging chores for all locales.
> > Makefiles allow each locale to be flexible in how directories and files
> > are organized, but that flexiblity comes at a bit of a maintenance
> > cost.
> 
> Nothing against Kim's makefiles, but I don't see them being necessary
> when (if?) we have site-wide automation.

I agree, but I wanted to be able to build a distribution already, and
anything in the Makefile's can be translated into Bourne Shell, or
whatever we want to use.  (PHP?)

If the packaging happens automatically after committing to the
repository it is fine to use a single method for building.

But I like to be able to build distributions as well, so I'd like to
keep a method around for myself to continue doing that.  For example,
if we create Windows BAT files for the central packaging, I'd need
something UNIXy.  The same might apply in reverse to those maintainers
who work in a Windows environment and cannot use Bourne Shell or make.

For a universal UNIX build system make(1) might not be the right tool,
either, unless we could agree on a dialect.  I'm using BSD make, and
GNU make is different...

> >> When I was automating the packaging, I thought it would have been much
> >> easier to place all files in a single tree, reflecting their proper
> >> location in the final distribution.  In other words:
> >>
> >> readme.html
> >> wp-config-sample.php
> >> wp-content/themes/default/...
> >> wp-includes/languages/fr_FR.po  (not that the .po file needs to be
> >> distributed
> >> wp-includes/languages/fr_FR.mo
> >>
> >> What's the benefit from placing the themes or the message file
> >> elsewhere?
> >
> > There's no need to replicate ugly directory structure.
> > Makefiles/scripts can put things where they need to be in the final
> > packaging.  Let's use automation to hide the annoying details.
> 
> Agreed.

That's fine with me -- I just found the automation simpler that way.

But fortunately we are also moving towards fewer files to translate,
so I bet I'll be completely agreeing with the both of you soon.

> >> However, it also has a second impact: the "source" files should not be
> >> distributed "as is."  They should be processed as part of the
> >> packaging, as implemented.  For example, the "source" files are in ISO
> >> 8859-1, because UTF-8 support still falls short on the UNIX systems I
> >> use.  I have set the svn:mime-type property accordingly.
> >
> > Older UNIX systems do indeed suck.  Newer Linux ones are usually UTF-8
> > out-of-the-box.  Regardless, UTF-8 makes the best source because it can
> > be converted to just about every other character set.  It is a
> > universal
> > donor.
> 
> Suggestion to Kim: perhaps you could iconv your files to UTF-8 before
> committing them? I know it'd be a little inconvenient for you on your
> older UNIX, but I'd really rather see all the source files in UTF-8. I
> share Ryan's feelings: UTF-8 is the best source to have.

If the charset is marked in the source files (e.g. using
svn:mime-type) then why should we make the translation work more
difficult for the maintainers?

I'd like to apply the same argument Ryan did above: let's use
automation to keep the ugly details away from the users.

Also, I think Ryan has it backwards: just about any other character
set can be translated to UTF-8, not the other way around.  So working
with source in any other charset perfectly allows distributing UTF-8
in the final package.

> > Automation proposal:  Allow locale Makefiles for those who want to
> > maintain them.  For those who don't, we'll provide a universal script
> > that will work with any properly structured locale.  When packaging
> > locales, the Makefile will be used if present.  Otherwise, the
> > universal
> > script is used.
> 
> Again, nothing against the makefiles, but I'd much prefer a transparent
> server-side solution that would make them unnecessary. Failing that
> though, I still don't see the need for different locales to do it
> different ways if we have one universal script.

I agree with Morgan: if a centralized packaging system is available, I
would like to make sure "my" locale works with it.  But that doesn't
rule out having other support structure within the locale.

Regards,
+ Kim