Sjur Nørstebø Moshagen wrote:
På 9. jul. 2004 kl. 13.12 skrev Upayavira:
This way it is possible for the subsequent i18n processing to cater
for country-(or whatever)-specific requirements in menus etc.
without the document itself necessarily being adjusted for such
variation.
Then, we can
=i18n src=content/*/{1}.xml
map:generate src={source}/
map:transform src=foo.xsl/
map:transform type=i18n
map:parameter name=locale value={locale}/
/map:transform
map:serialize type=html encoding={encoding}/ == support for
negotiated encoding!
/map:match
/map:match
Regards
På 9. jul. 2004 kl. 14.04 skrev Vadim Gritsenko:
I guess the full list would be: {lang}, {country}, {encoding},
{variant}, {full-locale}, {matched-locale}. {locale} could be a
shorthand for {full-locale}.
This list should be compatible with LocaleAction: language (not lang),
country, variant.
Sjur Nørstebø Moshagen wrote:
På 9. jul. 2004 kl. 14.04 skrev Vadim Gritsenko:
I guess the full list would be: {lang}, {country}, {encoding},
{variant}, {full-locale}, {matched-locale}. {locale} could be a
shorthand for {full-locale}.
This list should be compatible with LocaleAction: language
På 9. jul. 2004 kl. 14.16 skrev Upayavira:
Ok, but how do you decide which document version to serve then? Or
should Cocoon throw an error (No resource found)?
Exactly, if no default is given, the matcher doesn't match.
Ok - its crystal clear when you put it that way;)
Sjur
Upayavira wrote:
Sjur Nørstebø Moshagen wrote:
På 9. jul. 2004 kl. 14.04 skrev Vadim Gritsenko:
I guess the full list would be: {lang}, {country}, {encoding},
{variant}, {full-locale}, {matched-locale}. {locale} could be a
shorthand for {full-locale}.
This list should be compatible with
På 9. jul. 2004 kl. 14.33 skrev Vadim Gritsenko:
No, it should match document without locale - same behavior we have
now. Given your example:
file.ru_EE-KOI8.xml
file.ru_EE.xml
file.ru.xml
file.xml
And if none of the files above are present, *then* it should not match.
Given that we have defined
Vadim Gritsenko wrote:
Upayavira wrote:
Sjur Nørstebø Moshagen wrote:
På 9. jul. 2004 kl. 14.04 skrev Vadim Gritsenko:
I guess the full list would be: {lang}, {country}, {encoding},
{variant}, {full-locale}, {matched-locale}. {locale} could be a
shorthand for {full-locale}.
This list should be
Upayavira wrote:
...
Sorry, could we please delete the parts of the discussion that are not
strictly necessary from the replies? I have to keep on scrolling miles
of pages 8-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions
I'm building a 'document centric' internationalised site which, to my
mind, Cocoon can't 'quite' do yet. Cocoon's i18n functionality works
well on 'webapps', where you have snippets of text to be translated, but
not when the content is whole pages.
The most complex part of this is identifying
Hi All
I got an update to Cocoon 2.2.0-dev this morning, and pipelines that
use i18n like this:
map:transformer name=i18n
src=org.apache.cocoon.transformation.I18nTransformer
catalogues default=forms
catalogue id=local name=upload location=content/i18n/
catalogue id=forms name
Jeremy == Jeremy Quinn [EMAIL PROTECTED] writes:
Jeremy Hi All I got an update to Cocoon 2.2.0-dev this morning,
Jeremy and pipelines that use i18n like this:
Jeremy map:transformer name=i18n
Jeremy src=org.apache.cocoon.transformation.I18nTransformer
Jeremy catalogues
This looks like a known bug in ParamSaxBuffer. Sometimes SAX calls
characters() twice. The first call has the '{' and the second call has '}'.
ParamSaxBuffer can't handle that. The code currently has a FIXME comment
for this. I don't know if there is a workaround. I also don't know why
this
Ralph == Ralph Goers [EMAIL PROTECTED] writes:
Ralph This looks like a known bug in ParamSaxBuffer. Sometimes
Ralph SAX calls characters() twice. The first call has the '{'
Ralph and the second call has '}'. ParamSaxBuffer can't handle
Ralph that. The code currently has a FIXME
/show_bug.cgi?id=28869
Unmatched brackets in i18n dictionary cause OutOfMemoryError
Summary: Unmatched brackets in i18n dictionary cause
OutOfMemoryError
Product: Cocoon 2
Version: 2.1.3
Platform: All
OS/Version: Linux
Ralph Goers wrote:
map:transform type=i18n
...
If the values in the catalog contain things like jx:out
value=${request:}/ the I18n transformer will replace
{request:} with nothing leaving only the $ as the value. So what
we'd like to know is if there is any way
We ran into a little problem. In our I18n catalogs we want
to have variables which are dynamically replaced by variables in the request or
the session. So what we are doing is something like:
map:pipeline
internal=true
map:match pattern=Retrieve/**
map:generate src
Vadim Gritsenko wrote:
Upayavira wrote:
It seems that Cocoon's I18N code is more geared towards
internationalisation of 'webapps' rather than static sites.
It deals with menu items, etc, taking the various translations from
catalog files, as necessary.
However, when you want to build
Not sure about this particular character, but in i18n samples there are a
lot of exotic characters which are in CVS for quite a long time and there
were no any issues with them.
Take a look at the german translation, I think that it should contain
umlautes (somewhere arround
webapp/samples/i18n
It seems that Cocoon's I18N code is more geared towards
internationalisation of 'webapps' rather than static sites.
It deals with menu items, etc, taking the various translations from
catalog files, as necessary.
However, when you want to build a static site, where the entire content
Upayavira [EMAIL PROTECTED] writes:
snip/
Therefore, I think we need an I18N input module. It would do
something like:
map:match pattern=**/*.html
map:generate src={1}/{i18n:{2}.{locale}.xml/
...
/map:match
[NB. I'm not sure if nested input modules are allowed, so the syntax
Hunsberger, Peter wrote:
Upayavira [EMAIL PROTECTED] writes:
snip/
Therefore, I think we need an I18N input module. It would do
something like:
map:match pattern=**/*.html
map:generate src={1}/{i18n:{2}.{locale}.xml/
...
/map:match
[NB. I'm not sure if nested input modules are allowed
Unico Hommes [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Upayavira [EMAIL PROTECTED] writes:
snip/
Therefore, I think we need an I18N input module. It would do
something like:
map:match pattern=**/*.html
map:generate src={1}/{i18n:{2}.{locale}.xml
Hunsberger, Peter wrote:
Unico Hommes [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Upayavira [EMAIL PROTECTED] writes:
snip/
Therefore, I think we need an I18N input module. It would do
something like:
map:match pattern=**/*.html
map:generate src={1}/{i18n:{2}.{locale
Upayavira wrote:
It seems that Cocoon's I18N code is more geared towards
internationalisation of 'webapps' rather than static sites.
It deals with menu items, etc, taking the various translations from
catalog files, as necessary.
However, when you want to build a static site, where the entire
Hello ,
the last weeks I did some translations for the Lenya ui and today for
WoodyMessages. The problem is I have to use entities like #246; to use
german Umlaute in translated texts. Otherwise the apache cvs screws up
my umlauts.
IMHO it is ugly to commit i18n texts containing entities
Hi all,
it seems that the cache in I18n has a bug, or it's a feature?
The key and lookup for a translation table are not sidemap ambiguous
here a sample
file system:
root
|
+-- chemi with sidemap and i18n definition
| |
| - translation- general.xml
|
-- secure with sidemap
From: Vadim Gritsenko [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
kpiroumian2004/01/15 07:24:32
Modified:src/java/org/apache/cocoon/i18n BundleFactory.java
XMLResourceBundleFactory.java
src/java/org/apache/cocoon/transformation
/show_bug.cgi?id=26138
[PATCH] [i18n] Updated XMLResourceBundel, XMLResourceBundleFactory to detect changes
in underlying file and reload it
[EMAIL PROTECTED] changed:
What|Removed |Added
/show_bug.cgi?id=26138
[PATCH] [i18n] Updated XMLResourceBundel, XMLResourceBundleFactory to detect changes
in underlying file and reload it
[EMAIL PROTECTED] changed:
What|Removed |Added
[EMAIL PROTECTED] wrote:
kpiroumian2004/01/15 07:24:32
Modified:src/java/org/apache/cocoon/i18n BundleFactory.java
XMLResourceBundleFactory.java
src/java/org/apache/cocoon/transformation
I18nTransformer.java
src
/show_bug.cgi?id=26138
[PATCH] [i18n] Updated XMLResourceBundel, XMLResourceBundleFactory to detect changes
in underlying file and reload it
Summary: [PATCH] [i18n] Updated XMLResourceBundel,
XMLResourceBundleFactory to detect changes in underlying
file
/show_bug.cgi?id=26138
[PATCH] [i18n] Updated XMLResourceBundel, XMLResourceBundleFactory to detect changes
in underlying file and reload it
--- Additional Comments From [EMAIL PROTECTED] 2004-01-14 18:25 ---
Created an attachment (id=9951)
Contains modifications to XMLResourceBundle
Vadim Gritsenko wrote:
Hi all,
Currently I'm looking into i18n transformer... Couple of most irritating
problems I want to solve are:
* No reload of catalogues on change
This would be very cool!
* Crashes when message/ contains tag with attributes: messagebla a
href=bla bla /a bla /message
Bruno Dumon wrote:
On Sat, 2003-11-22 at 04:40, Vadim Gritsenko wrote:
Hi all,
Currently I'm looking into i18n transformer... Couple of most irritating
problems I want to solve are:
* No reload of catalogues on change
* Crashes when message/ contains tag with attributes: messagebla a
href
between the
two versions.
Browsing the docs, I can't see any change in the i18n markup. The
changes seem only to be in the component's configuration which now
accept several catalogues.
Did I miss some other important changes (I mean incompatible ones) ?
We had
change in the i18n markup. The
changes seem only to be in the component's configuration which now
accept several catalogues.
Did I miss some other important changes (I mean incompatible ones) ?
We had this discussion some time ago, and nobody seemed to remember
why it changed, but it changed
/show_bug.cgi?id=20445
i18n transformer does not recognize 2.0 namespace
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|CLOSED
SerializeNode.java
SitemapNodeBuilder.java
src/java/org/apache/cocoon/sitemap
DefaultSitemapComponentSelector.java
src/webapp/samples/i18n sitemap.xmap
Log:
Fix bug #22239 (views on resources don't work)
Revision
Bruno Dumon wrote:
This makes me think...
What about reverting the official i18n namespace to .../i18n/2.0 as
it was before ? This would allow warning-less compatibility of 2.0
applications and avoid breaking lots of docs, books, articles, etc.
Of course, we should provide legacy support
My trigger on i18n was late this time as I am on vacation, but I'd like to
explain why the namespace was changed.
A quot from changes list:
quot
Extended implementation of i18n transformer to allow markup in translations,
inline translations (conditional processing) and named parameters. Now i18n
/show_bug.cgi?id=20445
i18n transformer does not recognize 2.0 namespace
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Reading bugzilla mails will do it :-p
Joerg
Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
i18n transformer does not recognize 2.0 namespace
[EMAIL PROTECTED] changed:
What|Removed |Added
On Mon, 28 Jul 2003 22:40:25 -0400
Vadim Gritsenko [EMAIL PROTECTED] wrote:
Tetsuya Kitahata wrote:
snip/
Here I put (attached) a zipped file named i18n_japanized_sample.zip,
which contains:
1. messages_ja.xml
2. menu_ja.xml
Ok, checked in, but I have no even slightest idea what's in these
vgritsenko2003/07/28 19:36:31
Modified:src/webapp/samples/i18n/translations menu.xml menu_de.xml
menu_el.xml menu_en.xml menu_in.xml menu_ja.xml
menu_ko.xml menu_ru.xml menu_zh_CN.xml
menu_zh_TW.xml messages.xml
Hello, Cocoon-ers!
I modified sample i18n menu and message of japanese found at
/home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/
Here I put (attached) a zipped file named i18n_japanized_sample.zip,
which contains:
1. messages_ja.xml
2. menu_ja.xml
Please apply these files and commit
joerg 2003/07/19 08:21:04
Modified:src/java/org/apache/cocoon/i18n
XMLResourceBundleFactory.java
Log:
replaced deprecated ComponentException constructor
Revision ChangesPath
1.4 +122 -101
cocoon-2.1/src/java/org/apache/cocoon/i18n
201 - 247 of 247 matches
Mail list logo
