On Sat, Sep 29, 2012 at 2:40 PM, Dave Fisher <[email protected]> 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. >
