incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Call for comments: Webpage for Listing OpenOffice Consultants
Date Sat, 29 Sep 2012 20:55:42 GMT
On Sat, Sep 29, 2012 at 3:16 PM, Rob Weir <robweir@apache.org> wrote:
> On Sat, Sep 29, 2012 at 2:40 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>>
>> On Sep 29, 2012, at 2:25 AM, Andrea Pescetti wrote:
>>
>>> Rob Weir wrote:
>>>> A technical solution could be to put the strings into their own XML
>>>> file, so different localized versions could be used.  These would be
>>>> strings like column headers, the text of the disclaimer, etc.
>>>
>>> This would be perfect, and flexible enough.
>>
>> The CMS can be setup to build XML files from XSLT files with only some slight efforts
with perl.
>>
>> Here are eccn / exports from the lib/view.pm for www.apache.org:
>>
>> sub exports {
>>     my %args = @_;
>>     my $template = "content$args{path}";
>>     $args{breadcrumbs} = ASF::View::breadcrumbs($args{path});
>>
>>     my $page_path = $template;
>>     $page_path =~ s/\.[^.]+$/.page/;
>>     if (-d $page_path) {
>>         for my $f (grep -f, glob "$page_path/*.mdtext") {
>>             $f =~ m!/([^/]+)\.mdtext$! or die "Bad filename: $f\n";
>>             $args{$1} = {};
>>             read_text_file $f, $args{$1};
>>         }
>>         $args{table} = `xsltproc $page_path/eccnmatrix.xsl $page_path/eccnmatrix.xml`;
>>
>>     }
>>
>>     return Template($template)->render(\%args), html => \%args;
>> }
>>
>> and the lib/path.pm:
>>
>>     [qr!^/licenses/exports/index\.html$!, exports => {} ],
>>
>>
>> Done properly we can drop the NL files in a consistent area. Interesting...
>>
>> Ideally all that should be changed is the XML and then the site is properly rebuilt.
>>
>> What will this xlstproc call look like if there are two XML files - one for columns
and the other for data?
>>
>
> I don't know xsltproc, but most XSLT engines have a way to pass in an
> XSLT parameter via the command line.  So we'd pass in the locale id,
> e.g., "it" for Italian.  Then within the XSLT we could use the
> document() call to load a string resource file whose name is based in
> part on the locale, for example, strings_<locale>.xml. Or
> <locale>/strings.xml, depending on whether you want these centralized
> or not.
>

I've checked in a prototype of this.  It is not much to took at, but
it is real and demonstrates the data flow.

Anyone interested can check out:
https://svn.apache.org/repos/asf/incubator/ooo/devtools/consultants/

The data file is consultants.xml.  That should be valid according to
the consultants.xsd schema definition.

The to-html.xsl is the XSLT stylesheet that generates the output page.
 The display strings for that page are loaded from
strings_<locale>.xml.  I have an English version, and an Italian one
that is identical to the Italian version except it says "Ciao" in the
title.  For testing purposes only, of course.  But if anyone wants to
check in a real translations of those strings, it will be more
interesting.

The details of running this vary by XSLT processor.  For xsltproc, a
command line looks like:

xsltproc -o consultants.html --stringparam locale it to-html.xsl consultants.xml

Output is in consultants.html.  You can switch locales by setting
different values via stringparam parameter.

Regards,

-Rob


> But one other assumption to check:  can we pipeline the CMS processing
> steps together?  In other words, if we generate a bare-bones XHTML
> from the XSLT transform. can we then feed that XHTML back into the CMS
> to apply the usual template for the header/footer, etc.?
>
> -Rob
>
>
>> Regards,
>> Dave
>>
>>>
>>>> Another solution would be to have one master consultant listing, but
>>>> add a field to indicate the geographic scope of their business. ...
>>>> Pardon my ignorance here, but how do consultants tend to work in
>>>> Europe?  Are they easily able to offer services through the EU?
>>>
>>> This option is probably not needed. Individual consultants will often work within
one country only, and those who offer services in multiple countries can fill in multiple
applications (and then we would have the issue that geography and language do not map one-to-one,
so this approach couldn't be easily generalized).
>>>
>>> Regards,
>>>  Andrea.
>>

Mime
View raw message