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 19:16:59 GMT
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.

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