From: "Thomas Detoux" <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2007 17:26:41 +0100
Hello all,
My point is to show different versions of a picture for different
values of the users' locale, this will help for any picture with text
in it.
The first path explored was to have different picture for each locale :
* my_picture_en.jpg
* my_picture_fr.jpg
and to have sitemap replace a reference to /my_picture.jpg/ to the
correct localized version.
In order to reduce the number of images nedded, only the language part
of the locale is desired.
The org.apache.cocoon.matching.LocaleMatcher documentation indicated
that, among others, a *langage variable* was available within the
matcher, so I tried this :
========== BEGIN SITEMAP.XMAP SNAPSHOT ==============
[...]
<map:matcher logger="sitemap.matcher.locale" name="i18n"
src="org.apache.cocoon.matching.LocaleMatcher">
<locale-attribute>locale</locale-attribute>
<use-locale>true</use-locale>
<default-locale language="fr"/>
<create-session>false</create-session>
<store-in-request>true</store-in-request>
<store-in-session>false</store-in-session>
<store-in-cookie>false</store-in-cookie>
</map:matcher>
[...]
<map:match pattern="**/images/*.gif">
<map:match type="i18n">
<map:read mime-type="image/gif"
src="{system-property:site.home}/images/{2}_{language}.gif"/>
</map:match>
</map:match>
Did you actually mean {2} in there, or {../2}? I'd expect {2} to refer to a
value set by the i18n matcher rather than the surrounding wildcard matcher.
I must admit I've not actually used the locale matcher myself as I generally
use the locale action instead. From reading its javadocs, though, my
interpretation was that you must give it a pattern attribute as it will look
for the resource which most closely matches that path or filename after
expanding it with the locale-related values. So in your case you would have
something like
<map:match type="i18n"
pattern="{system-property:site.home}/images/{2}_*.gif">
<map:read mime-type="image/gif" src="{source}"/>
</map:match>
({2} is intentional this time as the variable has moved up a level to the
matcher's pattern instead of the reader's src). The "*" will try to match
language_country_variant, then language_country, then language, so if you
only use the language code in your images' filenames then that is all that
will be used. Although you could use
src="{system-property:site.home}/images/{../2}_{language}.gif" in the
reader, since the {source} variable gets set with the entire URI that
matched (after variable substitution) you might as well just use that
instead.
Alternatively, instead of the locale matcher you could always use the locale
action
<map:match pattern="**/images/*.gif">
<map:act type="locale">
<map:read mime-type="image/gif"
src="{system-property:site.home}/images/{../2}_{language}.gif"/>
</map:act>
</map:match>
The locale action is configured with much the same settings as the matcher,
and sets mostly the same variables (with the notable exception of {source}
since it acts entirely from the request and doesn't refer to any other
resources).
[...]
================END OF SNAPSHOT=============
Unfortunately, that doesn't work, server log sys :
(date) DEBUG [net.sf.ehcache.store.MemoryStore] cocoon-ehcache-1Cache:
MemoryStore miss for
PK_R-resource-file:/path/to/images/my_picture_.gif
As you can see, the /language/ is missing to the filename. When I try
to switch the two map:match, the log indicate that the server is
trying to reach file named *_en.gif* or *_fr.gif*.
Where is my mistake ? what's wrong ? Is there a better way to
internationalize pictures ?
Aha, so presumably the above example you gave was with the two matchers
already swapped over? That explains my confusion over {2} and {../2}. In
that case, when you had the matchers nested the opposite way round I would
expect {2} to return the base filename (my_picture) okay, but you would have
needed to use {../language} for the language code otherwise you are
referring to a variable set by the wildcard matcher (and the wildcard
matcher sets no such variable in its map). Variables aren't inherited by
nested matchers/actions/etc. as that might make values from outer levels
inaccessible. Instead you use "../" as many times as necessary to get back
out to the right level.
Thanks for reading me through the end, and thanks in advance for any
answer, clue or help.
regards.
Thomas Detoux
You're welcome.
Andrew.
--
http://pseudoq.sourceforge.net/ Open source java Sudoku application
_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.
http://www.msn.txt4content.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
