Re: [Wicket-user] i18n messages in HTML

I think maybe what we need to do is keep a list of default behaviours in application somewhere, and those get added to every new component. maybe not a list but a callback much like the iauthorizationpolicy does now. Application.initializeComponent(Component c) that way you can add an attr modifi

Re: [Wicket-user] i18n messages in HTML

Andrew Berman wrote: I think the attribute feature should be removed. I think it is just un-Wicket-like, and I think others agree as I read form the emails in this thread. As I mentioned before I think when it comes to attributes, it is best to just do it from within the component manually

Re: [Wicket-user] i18n messages in HTML

Juergen Donnerstag wrote: I've implemented it last night. Was fairly easy. I'll commt it tonight. Default value Heh, excellent, I think the above two will cover pretty much the cases where it doesn't fit do develop a new component just to change a message based on the locale. Thanks

Re: [Wicket-user] i18n messages in HTML

Laurent PETIT wrote: Hello, On 11/9/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: You mean for tag text, correct? What do you think about . Than it is clear that the whole label is wicket specific, This sounds quite similar as what I posted 5 hours ago : (extract) " A text to

Re: [Wicket-user] i18n messages in HTML

I think/ agree that while Wicket's strong point lies in the fact that we keep things clean and code-centric, having easy localized string replacement without going through the whole requirement of having Wicket components in a matching hierarchy is a very good exception to the rule. Eelco On 11/

Re: [Wicket-user] i18n messages in HTML

Yes, the attribute thing doesn't realy look wicket like, that is true. But I still think that some kind of i18n (message) retrieval e.g. for button texts can be improved. A button is something I would like to be easily modifyable especially in multi-language application. Of course you can do it alr

Re: [Wicket-user] i18n messages in HTML

Jeurgen,    I think the attribute feature should be removed.  I think it is just un-Wicket-like, and I think others agree as I read form the emails in this thread.  As I mentioned before I think when it comes to attributes, it is best to just do it from within the component manually instead of the

Re: [Wicket-user] i18n messages in HTML

First draft version available in CVS HEAD Juergen On 11/10/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > I've implemented it last night. Was fairly easy. I'll commt it tonight. > > Default value > > > > As wicket core is very much pluggable, it can easily be added / removed. > > Juergen >

Re: [Wicket-user] i18n messages in HTML

I've implemented it last night. Was fairly easy. I'll commt it tonight. Default value As wicket core is very much pluggable, it can easily be added / removed. Juergen On 11/9/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > +1 > > -Igor > > > On 11/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> w

Re: [Wicket-user] i18n messages in HTML

+1 -Igor On 11/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I think would fit well with our other wicket tags, e.g .IMHO such an addition would be very useful.Sven>>You mean for tag text, correct? >>What do you think about .  Than it is clear>that the whole label is wicket specific,>> is a

Re: [Wicket-user] i18n messages in HTML

[EMAIL PROTECTED] wrote: Every time we're running into syntax discussions (see 'replacing OGNL') I feel that Wicket is deviating from the Java way. I think all the following suggestions would better be left unimplemented: ... Hello. Although most of these were my suggestions, I agree. Th

Re: [Wicket-user] i18n messages in HTML

Every time we're running into syntax discussions (see 'replacing OGNL') I feel that Wicket is deviating from the Java way. I think all the following suggestions would better be left unimplemented: ... Hello. This is leaning in the direction of Tapestry (with special $prefixes) or real attri

Re: [Wicket-user] i18n messages in HTML

the whole idea is of this thread that we don't want to have to add all kind of components on every place to localize youre html of all youre labels. I do see a good reason for that (maybe you as an american don's use i18n a lot ;)) Now i have slept a night over it i think we need to keep it simpl

Re: [Wicket-user] i18n messages in HTML

Most of em do, though we all have kind of our different 'expertises'. The currently active developers are yours truly, Juergen, Johan, Igor and Martijn, though Martijn is mainly doing site/ builds/ promotion etc. Gwyn is the man for Wiki. Jonathan is not really active, but does some work in the bac

Re: [Wicket-user] i18n messages in HTML

I think this is starting to get all out of hand and when I suggested this whole thing I didn't think it was going to be crazy like this.  Perhaps the attribute thing is best left to doing it the normal Wicket way.  I think the only thing I really need for i18n in terms of changing attributes is for

Re: [Wicket-user] i18n messages in HTML

Johan Compagner wrote: then call it wicket:message="value=my-key" so that Default Text and uses the same kind of notation. I can't decide if I like this idea or not. I like the idea of having as few separate constructs as possible, but I'm not sure I like using the same word for a tag n

Re: [Wicket-user] i18n messages in HTML

Hmm isnt all this already possible without having to do anything? public class Message extends WebMarkupContainer {     public Message(String id)     {         super(id);     }     protected void onComponentTagBody(MarkupStream markupStream, ComponentTag openTag)     {         ValueMap attrs=openT

Re: [Wicket-user] i18n messages in HTML

oh and btw, rendering the same component more then once on a page will throw HEAD into an infinite loop while it works quiet well in 1.0 and 1.1. Should i write up a bug or is this part of someone's work in progress? -Igor On 11/9/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: Hmm isnt all this alre

Re: [Wicket-user] i18n messages in HTML

You cannot really compare wicket to tapestry. Although they are both component oriented frameworks, they have completely different approaches. In wicket the focus is on java code not on the template. Wicket templates are simple and limited (purposefully) where as tapestry allows for a lot more cust

Re: [Wicket-user] i18n messages in HTML

just realized its not going to work in a hierarchy of components never mind -Igor On 11/9/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: oh and btw, rendering the same component more then once on a page will throw HEAD into an infinite loop while it works quiet well in 1.0 and 1.1. Should i writ

Re: [Wicket-user] i18n messages in HTML

I dont like lets keep our html modifications only to components and tags in wicket namespace. Its pretty easy to create a webmarkupcontainer that will do this replace. -Igor On 11/9/05, Johan Compagner <[EMAIL PROTECTED]> wrote: i can live with: Default Text and But i think the second one

Re: [Wicket-user] i18n messages in HTML

2005/11/9, Andrew Berman <[EMAIL PROTECTED]>: Oh and the other nice feature would be that if you do it like this: My Text that the My Text would be the default text if the key is not found.   How about using the content as the key keyLabel?   And for _javascript_, I think it could be possible to

Re: [Wicket-user] i18n messages in HTML

Hello, What about something like that: Use one of the two forms (both could be allowed): A text to render or my.msg.key Of course, this introduces a new element in the wicket namespace ... Or something like that: Any text you want or Any text you want and create a hook in wicket (if it does n

Re: [Wicket-user] i18n messages in HTML

Problem with that is that is not valid xml. Eelco On 11/9/05, Andrew Berman <[EMAIL PROTECTED]> wrote: > I like as long as it would work how normal JSP > tags currently work. In other words, I would be able to do this: > > > > or > > >alert(""); > > > > -

Re: [Wicket-user] i18n messages in HTML

Other way of handle tranlations can be take and aproach simiar to Qt ui tollkit i try to explain it a bit whe you localiced and application all string in html are desired to be translate we can parser html files and assign and unique id to each string to be translate provide a singuel file for

Re: [Wicket-user] i18n messages in HTML

can't say i have a real preference. Somehow wicket:message looks better because i18n looks like capitals But that is just a feeling. And i still don't know if it is i18n or should it be l10n? (localisation) Because you do Localize youre page itself. But the template is maybe i18n On 11/9/05, Juerge

Re: [Wicket-user] i18n messages in HTML

One more idea. How about using some reserved word for wicket:id. Like this:     This would create an automatic component (with a behaviour) that scans all attributes and does its magic. This could be easily extended to other scenarios too.   /arto 

Re: [Wicket-user] i18n messages in HTML

yesm true. do you prefer wicket:mesage or wicket:i18n? Juergen On 11/9/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > then call it wicket:message="value=my-key" > > so that > > Default Text > and > > > uses the same kind of notation. > > Als value="My Val" can then be seen as the defaul

Re: [Wicket-user] i18n messages in HTML

Thats an RFE already. I'm not yet sure what the best approach is. Just thinking. Juergen On 11/9/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > ok then pre process and do it at markup loading time. > The only problem i see with this then that people will start to complaind > that they don't >

Re: [Wicket-user] i18n messages in HTML

then call it wicket:message="value=my-key" so that Default Text and   uses the same kind of notation. Als value="My Val" can then be seen as the default value if the value is not found for the given locale? That would be nice i think. johan On 11/9/05, Juergen Donnerstag <[EMAIL PROTECTED]>

Re: [Wicket-user] i18n messages in HTML

ok then pre process and do it at markup loading time. The only problem i see with this then that people will start to complaind that they don't see changes when they alter there messages So suddenly we also have to watch those?? johan On 11/9/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: On

Re: [Wicket-user] i18n messages in HTML

good idea, except I would like to make a "=". wicket:i18n="value=my-key" Juergen On 11/9/05, Scott Sauyet <[EMAIL PROTECTED]> wrote: > Johan Compagner wrote: > > i can live with: > > > > Default Text > > This makes sense. > > > > > I don't think this one does. It breaks the previewability of pa

Re: [Wicket-user] i18n messages in HTML

On 11/9/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > if you do the replacement at parse time. > then every html in the markup cache is specified by a locale? > (even if there is not locale in the name of the html) > Thats already the case. The markup id includes locale style etc. But multipl

Re: [Wicket-user] i18n messages in HTML

Johan Compagner wrote: i can live with: Default Text This makes sense. I don't think this one does. It breaks the previewability of pages which is one of Wicket's hallmarks. How about something like wicket:attr="value:message:my-key"/> or wicket:i18n="value:my-key" Wicket

Re: [Wicket-user] i18n messages in HTML

Hello, On 11/9/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > You mean for tag text, correct? > > What do you think about . Than it is clear > that the whole label is wicket specific, This sounds quite similar as what I posted 5 hours ago : (extract) " A text to render " I personally thin

Re: [Wicket-user] i18n messages in HTML

if you do the replacement at parse time. then every html in the markup cache is specified by a locale? (even if there is not locale in the name of the html) To me it looks like that But we could store one for every locale we encouter if that is faster/better somehow johan On 11/9/05, Juergen Don

Re: [Wicket-user] i18n messages in HTML

We have different options (as explained in my first mail) - do the replacement while loading the markup, prior to xml reading it. The cached version will have the messages replaced - analyze the attributes while reading xml. The cached version will have the messages replaced for the attrbutes. wil

Re: [Wicket-user] i18n messages in HTML

Hmmmwell, I do think it would provide value to have the attribute way as well.  How much slower do you think it is going to make it?  Anyone else have any suggestions? --AndrewOn 11/9/05, Johan Compagner < [EMAIL PROTECTED]> wrote:i can live with: Default Text and But i think the second

Re: [Wicket-user] i18n messages in HTML

> Default Text > > and > > > > But i think the second one will be pretty hard. > Because then we have to parse the complete xml and see if in any attribute > something starts with message:key > even for non wicket tags as above? > we have to do it anyway to identify wicket tags. Only analyz

Re: [Wicket-user] i18n messages in HTML

i can live with: Default Text and But i think the second one will be pretty hard. Because then we have to parse the complete xml and see if in any attribute something starts with message:key even for non wicket tags as above? johan On 11/9/05, Andrew Berman <[EMAIL PROTECTED]> wrote: Oh and t

Re: [Wicket-user] i18n messages in HTML

Well, I guess not being able to do it in _javascript_ would be ok, but I think there definitely needs to be a way to do it in attributes.Here is the link for how Tapestry 4.0 does it: http://jakarta.apache.org/tapestry/UsersGuide/localization.html--AndrewOn 11/9/05, Juergen Donnerstag < [EMAIL PRO

Re: [Wicket-user] i18n messages in HTML

Oh and the other nice feature would be that if you do it like this: My Text that the My Text would be the default text if the key is not found. On 11/9/05, Andrew Berman <[EMAIL PROTECTED]> wrote: Well, I guess not being able to do it in _javascript_ would be ok, but I think there definitely needs

Re: [Wicket-user] i18n messages in HTML

On 11/9/05, Andrew Berman <[EMAIL PROTECTED]> wrote: > I like as long as it would work how normal JSP > tags currently work. In other words, I would be able to do this: > > > > or > > >alert(""); > > No, that was not the intend and I don't like it either.

Re: [Wicket-user] i18n messages in HTML

I like as long as it would work how normal JSP tags currently work.  In other words, I would be able to do this: or
   alert("");
--AndrewOn 11/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I think would fit well with our other wicket tags, e.g .IMHO su

Re: [Wicket-user] i18n messages in HTML

I think would fit well with our other wicket tags, e.g . IMHO such an addition would be very useful. Sven > >You mean for tag text, correct? > >What do you think about . Than it is clear >that the whole label is wicket specific, > > is a bit dangerous because how would we >handle ? > >Juerge

Re: [Wicket-user] i18n messages in HTML

Thanks for the response. How are your questions related to i18n messages? Sorry I missunderstood the i18n question. I read the preprocessing of the tag-body you mentioned and thought - well the wrong thing. Thanks, Christian

Re: [Wicket-user] i18n messages in HTML

You mean for tag text, correct? What do you think about . Than it is clear that the whole label is wicket specific, is a bit dangerous because how would we handle ? Juergen On 11/9/05, Dorel Vaida <[EMAIL PROTECTED]> wrote: > Juergen Donnerstag wrote: > > >I'm all for making things easier fo

Re: [Wicket-user] i18n messages in HTML

Juergen Donnerstag wrote: I'm all for making things easier for the user. Perhaps Wicket could have something like this: I'm not sure this makes sense. wicket:id is not a text to be displayed anywhere. It is a name which identifies a component. It definitely won't work. Actually,

Re: [Wicket-user] i18n messages in HTML

On 11/9/05, Christian Essl <[EMAIL PROTECTED]> wrote: > I had a similar problem with JavaScript inside a

Re: [Wicket-user] i18n messages in HTML

I had a similar problem with JavaScript inside a

Re: [Wicket-user] i18n messages in HTML

I'm all for making things easier for the user. > Perhaps Wicket could have something like this: > I'm not sure this makes sense. wicket:id is not a text to be displayed anywhere. It is a name which identifies a component. It definitely won't work. > Even better would be that it would recognize