Menu
▾
▴
bodington-developers
|
From: Matthew B. <mat...@co...> - 2005-07-15 11:06:08
|
Alistair Young wrote: > There's nothing stopping someone changing the language to "ru" and getting > an unusable bod. Shouldn't Bod just display the default strings (english?) if the translated version of some resource doesn't exist. Otherwise we get to the situation that someone does a translation to french for example. Then we add some new tools (eg my ACL tool) which uses i18n. Now we have the situation where unless someone translates the ACL tool french users won't be able to upgrade as they will no longer be able to select french as the language. We need to have the idea of a default language that the localiser falls back to if it can't find the localised version of that string. This way we don't have to delay software releases so that all the translators can do thier work. Isn't it better to have some parts of the application localised than none? -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 11:13:05
|
> Isn't it better to have some parts of the application > localised than none? agreed - do you want this for 2.6? could probably delegate missing string= s to the default language. Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Alistair Young wrote: > >> There's nothing stopping someone changing the language to "ru" and >> getting >> an unusable bod. > > Shouldn't Bod just display the default strings (english?) if the > translated version of some resource doesn't exist. > > Otherwise we get to the situation that someone does a translation to > french for example. Then we add some new tools (eg my ACL tool) which > uses i18n. > > Now we have the situation where unless someone translates the ACL tool > french users won't be able to upgrade as they will no longer be able to > select french as the language. > > We need to have the idea of a default language that the localiser falls > back to if it can't find the localised version of that string. This way > we don't have to delay software releases so that all the translators ca= n > do thier work. Isn't it better to have some parts of the application > localised than none? > > > -- > +--Matthew Buckett-----------------------------------------+ > | VLE Developer, Learning Technologies Group | > | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | > +------------Computing Services, University of Oxford------+ > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Matthew B. <mat...@co...> - 2005-07-14 09:28:33
|
Alistair Young wrote: >>So you hardcode the resource >>properties in the .java file that the compiler produces? > > yes. There was a debate ages ago whether to substitute a <localise> > element with the actual text or write code into the template class to > dynamically call the Localiser. We choose the dynamic method as that lets > you update the properties file without recompiling the template. But doesn't XmlTemplate.getCharacterData() insert an hard coded string into the Java file? parent.appendChild(parent.getOwnerDocument().createTextNode(res.getString(idAttr.getNodeValue()))); -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Alistair Y. <ali...@sm...> - 2005-07-14 09:35:43
|
yep, no way round that. literals are passed to Facility methods so I can't pass a Localiser method call instead of a string. It has to be a java.lang.String that gets passed to Facility. It's a fundamental i18n limitation of bod. You need to recompile the template if you change a Facility literal string in a properties file. For all other "normal" content, i.e. content that the template class displays, you don't need to recompile if you change the properties file. Templates delegating content display to Facility causes the problem. Alistair On 14 Jul 2005, at 10:28, Matthew Buckett wrote: > Alistair Young wrote: > >>> So you hardcode the resource >>> properties in the .java file that the compiler produces? >>> >> yes. There was a debate ages ago whether to substitute a <localise> >> element with the actual text or write code into the template class to >> dynamically call the Localiser. We choose the dynamic method as >> that lets >> you update the properties file without recompiling the template. >> > > But doesn't XmlTemplate.getCharacterData() insert an hard coded > string into the Java file? > parent.appendChild(parent.getOwnerDocument().createTextNode > (res.getString(idAttr.getNodeValue()))); > > -- > +--Matthew Buckett-----------------------------------------+ > | VLE Developer, Learning Technologies Group | > | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | > +------------Computing Services, University of Oxford------+ > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in > dual > core and dual graphics technology at this free one hour event > hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/ > go/dualwebinar > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Matthew B. <mat...@co...> - 2005-07-14 09:57:10
|
Alistair Young wrote:
> yep, no way round that. literals are passed to Facility methods so I
> can't pass a Localiser method call instead of a string. It has to be a
> java.lang.String that gets passed to Facility. It's a fundamental i18n
> limitation of bod. You need to recompile the template if you change a
> Facility literal string in a properties file. For all other "normal"
> content, i.e. content that the template class displays, you don't need
> to recompile if you change the properties file.
> Templates delegating content display to Facility causes the problem.
The reason I orginally wrote the patch is I couldn't see any support for
dynamically changing and I didn't look inside getCharacterData().
With my patch when you compile the call from default/applettop.html:
<call>
<target method="variable"><variable name="facility"/></target>
<parameters>
<variable name="request"/>
<variable name="writer"/>
<literal type="String">
<localise id="page.title.text"/>
</literal>
</parameters>
</call>
you get this in the Java:
facility .variable( request , writer , res.getString("page.title.text") );
otherwise you get the hardcoded string.
facility .variable( request , writer , "title" );
Is this better?
--
+--Matthew Buckett-----------------------------------------+
| VLE Developer, Learning Technologies Group |
| Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ |
+------------Computing Services, University of Oxford------+
|
|
From: Alistair Y. <ali...@sm...> - 2005-07-14 10:05:51
|
nice one! that'll do. My only concern was it caused NPE with style_0/
recycler/main.html. That's nothing to do with the template
compilation problem. It's a nice enhancement for dynamic localisation
though. Before you commit, can you make sure you're not seeing any
NPE with non localised templates?
Who's going to update the ant task to fix the template compilation
problem?
Alistair
On 14 Jul 2005, at 10:57, Matthew Buckett wrote:
> Alistair Young wrote:
>
>> yep, no way round that. literals are passed to Facility methods so
>> I can't pass a Localiser method call instead of a string. It has
>> to be a java.lang.String that gets passed to Facility. It's a
>> fundamental i18n limitation of bod. You need to recompile the
>> template if you change a Facility literal string in a properties
>> file. For all other "normal" content, i.e. content that the
>> template class displays, you don't need to recompile if you
>> change the properties file.
>> Templates delegating content display to Facility causes the problem.
>>
>
> The reason I orginally wrote the patch is I couldn't see any
> support for dynamically changing and I didn't look inside
> getCharacterData().
>
> With my patch when you compile the call from default/applettop.html:
>
> <call>
> <target method="variable"><variable name="facility"/></target>
> <parameters>
> <variable name="request"/>
> <variable name="writer"/>
> <literal type="String">
> <localise id="page.title.text"/>
> </literal>
> </parameters>
> </call>
>
> you get this in the Java:
>
> facility .variable( request , writer , res.getString
> ("page.title.text") );
>
> otherwise you get the hardcoded string.
>
> facility .variable( request , writer , "title" );
>
> Is this better?
>
> --
> +--Matthew Buckett-----------------------------------------+
> | VLE Developer, Learning Technologies Group |
> | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ |
> +------------Computing Services, University of Oxford------+
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in
> dual
> core and dual graphics technology at this free one hour event
> hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/
> go/dualwebinar
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>
|
|
From: Alexis O'C. <ale...@co...> - 2005-07-14 10:12:41
|
Alistair Young wrote: > nice one! that'll do. My only concern was it caused NPE with style_0/ > recycler/main.html. That's nothing to do with the template compilation > problem. It's a nice enhancement for dynamic localisation though. > Before you commit, can you make sure you're not seeing any NPE with non > localised templates? > > Who's going to update the ant task to fix the template compilation > problem? > > Alistair > We're happy to do that (enable the language setting to be overridden) from the ANT build. We'll probably also insert a default language setting lower down the object call graph for the sake of correctness. Alexis |
|
From: Alistair Y. <ali...@sm...> - 2005-07-14 10:18:33
|
> We'll probably also insert a default language setting lower down > the object call graph for the sake of correctness. when will you do this? the templates won't compile from the commandline until the task is updated. Alistair On 14 Jul 2005, at 11:12, Alexis O'Connor wrote: > Alistair Young wrote: > >> nice one! that'll do. My only concern was it caused NPE with >> style_0/ recycler/main.html. That's nothing to do with the >> template compilation problem. It's a nice enhancement for dynamic >> localisation though. Before you commit, can you make sure you're >> not seeing any NPE with non localised templates? >> Who's going to update the ant task to fix the template >> compilation problem? >> Alistair >> > > We're happy to do that (enable the language setting to be > overridden) from the ANT build. > > We'll probably also insert a default language setting lower down > the object call graph for the sake of correctness. > > > Alexis > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in > dual > core and dual graphics technology at this free one hour event > hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/ > go/dualwebinar > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Alexis O'C. <ale...@co...> - 2005-07-14 10:37:11
|
Alistair Young wrote: >> We'll probably also insert a default language setting lower down the >> object call graph for the sake of correctness. > > when will you do this? the templates won't compile from the commandline > until the task is updated. > > Alistair > We'll do this very soon. I'm currently updating the template to resource mapping in style_default/default! As a (very) short term solution, the template-compiler task within the compile-templates target is an implicit FileSet, so you can explictly [in | ex} clude the files you're interested in. Alexis |
|
From: Matthew B. <mat...@co...> - 2005-07-14 10:19:06
|
Alistair Young wrote:
> nice one! that'll do. My only concern was it caused NPE with style_0/
> recycler/main.html.
Was that a NPE at compile or runtime?
> That's nothing to do with the template compilation
> problem. It's a nice enhancement for dynamic localisation though.
> Before you commit, can you make sure you're not seeing any NPE with non
> localised templates?
Ok. I'll also remove your for localisation from getCharacterData(). One
thing to note is I change the syntax for localised facility calls from:
<call>
<target method="variable"><variable name="facility"/></target>
<parameters>
<variable name="request"/>
<variable name="writer"/>
<literal type="String">
<localise id="page.title.text"/>
</literal>
</parameters>
</call>
to:
<call>
<target method="variable"><variable name="facility"/></target>
<parameters>
<variable name="request"/>
<variable name="writer"/>
<localise id="page.title.text"/>
</parameters>
</call>
But my orginal patch include fixing the templates that were affected.
--
+--Matthew Buckett-----------------------------------------+
| VLE Developer, Learning Technologies Group |
| Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ |
+------------Computing Services, University of Oxford------+
|
|
From: Alistair Y. <ali...@sm...> - 2005-07-14 10:31:12
|
I don't follow now. Is this not overkill? The problem was the ant task not setting the language. Changing the format of Facility calls is not a good idea so near a release, is it? All that needs done is to update the ant task to set the language from the build.properties. No other patches are required. You spotted an enhancement for dynamically localised Facility calls but it's not required for 2.6, unless you're confident it works in all templates. It would also mean we could bin the language propagation from Template to XmlTemplate. Can we just put the enhancement patches aside for now, update the ant task and see if template compilation works? If so, we can then proceed with any efficiency enhancements but I'm not happy about doing it so near the release. Alistair On 14 Jul 2005, at 11:18, Matthew Buckett wrote: > Alistair Young wrote: > >> nice one! that'll do. My only concern was it caused NPE with >> style_0/ recycler/main.html. >> > > Was that a NPE at compile or runtime? > > > That's nothing to do with the template compilation > >> problem. It's a nice enhancement for dynamic localisation though. >> Before you commit, can you make sure you're not seeing any NPE >> with non localised templates? >> > > Ok. I'll also remove your for localisation from getCharacterData(). > One thing to note is I change the syntax for localised facility > calls from: > > <call> > <target method="variable"><variable name="facility"/></target> > <parameters> > <variable name="request"/> > <variable name="writer"/> > <literal type="String"> > <localise id="page.title.text"/> > </literal> > </parameters> > </call> > > to: > > <call> > <target method="variable"><variable name="facility"/></target> > <parameters> > <variable name="request"/> > <variable name="writer"/> > <localise id="page.title.text"/> > </parameters> > </call> > > But my orginal patch include fixing the templates that were affected. > > -- > +--Matthew Buckett-----------------------------------------+ > | VLE Developer, Learning Technologies Group | > | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | > +------------Computing Services, University of Oxford------+ > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in > dual > core and dual graphics technology at this free one hour event > hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/ > go/dualwebinar > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Alexis O'C. <ale...@co...> - 2005-07-15 10:41:02
|
Alistair Young wrote: > Thanks Alexis. > > I'm not sure what you mean by language agnostic. Bod is now an i18n > application so the template compiler must be language aware. By that I > mean the compiler has to know which language variant to build. > Ok, it's not *really* that much of a problem, but you've drawn me, so I shall respond ;-). I think the fact that templates for different languages get compiled is inherently duff. Conceptually, there should be one single generic set of templates that dynamically pull in the resource bundles at run-time. When you compile the templates stand-alone, you're really just wanting to see that their valid (i.e. are valid XML and can compile into java). The available languages should be neither here nor there. The current situtation implies that you need to seperately compile the templates for all the languages that you know about. As I say, no need for anyone to get upset ;-). Alexis |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 10:58:20
|
> there should be one single generic set of > templates that dynamically pull in the resource bundles at run-time there's only one set of templates for all languages and compiling them at build time tells you they're valid xml etc. The template *class* is language specific in that it has a pointer to a language specific Localiser, to get it's strings. Bod isn't ever in "one" language, it can be in hundreds at the same time. You can have French, Italian, Russian, Gaelic users all using the same bod and all seeing the templates in their own language. At the time there were two options to do this: 1 - have a language specific resource url - wouldn't work for tracking etc. (you haven't viewed your document, yes I have, I viewed the Russian one) 2 - have a language specific template class and have the template compile= r return that. Now that I know more about the gloabl soup of bod I could perhaps do away with language specific template classes and write logic into the template class to get the current user, get their language and grab an instance of a Localiser for that language. It then comes down to performance. Either XmlTemplate "redirects" to the language specifc template class, as it does just now, or the template class itself works out which language it should work in. I'd be interested to hear your opinion on all this Alexis as you know a lot more about the bod guts than me (thank goodness!) Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Alistair Young wrote: >> Thanks Alexis. >> >> I'm not sure what you mean by language agnostic. Bod is now an i18n >> application so the template compiler must be language aware. By that I >> mean the compiler has to know which language variant to build. >> > > Ok, it's not *really* that much of a problem, but you've drawn me, so I > shall respond ;-). > > I think the fact that templates for different languages get compiled is > inherently duff. Conceptually, there should be one single generic set o= f > templates that dynamically pull in the resource bundles at run-time. > When you compile the templates stand-alone, you're really just wanting > to see that their valid (i.e. are valid XML and can compile into java). > The available languages should be neither here nor there. The current > situtation implies that you need to seperately compile the templates fo= r > all the languages that you know about. > > As I say, no need for anyone to get upset ;-). > > Alexis > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Matthew B. <mat...@co...> - 2005-07-15 11:24:38
|
Alistair Young wrote: >>Isn't it better to have some parts of the application >>localised than none? > > agreed - do you want this for 2.6? could probably delegate missing strings > to the default language. Should we have string.properties - Contains the english language strings string_fr.properties - Contains the french language properties. This way if someone selects english as the language it just uses the defaults (which happen to be english). Otherwise if someone selects french then the _fr files are used but we fall back to english if a property doesn't exist. If someone selects russian then they still see the english? This is how ResourseBundle works: http://java.sun.com/j2se/1.4.2/docs/api/java/util/ResourceBundle.html -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Alistair Y. <ali...@sm...> - 2005-07-15 11:33:38
|
> string.properties but you've just binned strings.properties! only joking, I know what you m= ean. > This is how ResourseBundle works: really? well I never ;) Alistair --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Alistair Young wrote: >>>Isn't it better to have some parts of the application >>>localised than none? >> >> agreed - do you want this for 2.6? could probably delegate missing >> strings >> to the default language. > > Should we have > > string.properties - Contains the english language strings > string_fr.properties - Contains the french language properties. > > This way if someone selects english as the language it just uses the > defaults (which happen to be english). > > Otherwise if someone selects french then the _fr files are used but we > fall back to english if a property doesn't exist. > > If someone selects russian then they still see the english? > > This is how ResourseBundle works: > > http://java.sun.com/j2se/1.4.2/docs/api/java/util/ResourceBundle.html > > -- > +--Matthew Buckett-----------------------------------------+ > | VLE Developer, Learning Technologies Group | > | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | > +------------Computing Services, University of Oxford------+ > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X