Menu
▾
▴
bodington-developers — Mailing list for Bodington developers
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(41) |
May
(353) |
Jun
(133) |
Jul
(534) |
Aug
(401) |
Sep
(219) |
Oct
(86) |
Nov
(144) |
Dec
(61) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(200) |
Feb
(130) |
Mar
(345) |
Apr
(153) |
May
(247) |
Jun
(338) |
Jul
(222) |
Aug
(70) |
Sep
(39) |
Oct
(27) |
Nov
(76) |
Dec
(30) |
| 2007 |
Jan
(81) |
Feb
(44) |
Mar
(9) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(34) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(6) |
| 2008 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Alexis O'C. <ale...@co...> - 2005-05-24 15:30:13
|
Alexis O'Connor wrote: > Alistair Young wrote: > >> there's a new one in head - if you want to try it on windows - you'll >> need to delete any compiled templates first to get rid of the old >> problem this addresses. >> >> if those with windows machines could let me know if it helps... >> >> Alistair >> > > Not quite, my diagnosis was slightly wrong :-(. > > It's to do with escaping the backslash in strings, so actually we're > closer than we were before. I attach the contents of the compilation > error file. > > Alexis Or (replying to my own post) you could get the Localiser constructor to accept a file name in URL format, e.g. file://[...]. Outputting the path in URL format would clearly circumvent the 'escaping backslashes in strings' problem. Alexis |
|
From: Alexis O'C. <ale...@co...> - 2005-05-24 15:15:05
|
Alistair Young wrote: > there's a new one in head - if you want to try it on windows - you'll > need to delete any compiled templates first to get rid of the old > problem this addresses. > > if those with windows machines could let me know if it helps... > > Alistair > Not quite, my diagnosis was slightly wrong :-(. It's to do with escaping the backslash in strings, so actually we're closer than we were before. I attach the contents of the compilation error file. Alexis |
|
From: Alistair Y. <ali...@sm...> - 2005-05-24 15:01:26
|
> HTML translates all tabs, spaces and newlines into a space yes but a newline in a properties value breaks the properties file. web devs use line breaks in gui editors to make it nicer to see what they're doing. They'd have to remove all linebreaks before putting the content in a properties value. I keep banging on about web devs (rollnecks) but when you think about it, you can't use bod templates in a rollneck ide anyway as they're so naff (the templates, not the rollnecks!) I mentioned tmx to test the water. It's cutting edge and groovy, yes. So, the middle ground. I've already chucked away one version of i18n and I'm prepared to chuck more if need be. head could have been a lot worse - I don't commit everything! what about xml properties files sitting in the classpath, one per template, per language? Alistair On 24 May 2005, at 15:42, Matthew Buckett wrote: > I'm not saying Alistair Young wrote: >>> What problems do you envisage? >> outside of classpath I have to worry about windows - do I have time? >> no! > > :-) > >>> Does this make it harder for people to be working on translations at >>> the same time as someone has to merge the files back together >> not sure yet - tmx files are designed to be used with translation > > Properties files are also designed to be loaded into translation > software and they are probably supported by more translation software > than TMX. > >> applications rather than hand editors. Anyway, that's how cvs works. >> I would think that users would donate translations to the community >> and we would be responsible for merging them into the tree, just as >> we are for code. > > Seems to be making more work for us. > >>> What do we gain? >> each template has only one resource file rather than, say 10 > > How is that better? > >>> What is wrong with the properties file approach? >> the biggest problem I've found is the fact that properties files are >> meant for strings, not content. You can't have linebreaks in a >> properties file value. As most web devs put these in to make it >> easier to design, they'd have to remove them to localise the >> template. XML gets round this problem. > > HTML translates all tabs, spaces and newlines into a space (unless > inside a <pre>, I forget the CSS equivelent). > >>> Doesn't this mean someone has to have an understanding of XML >> not necessarily - we must stop thinking as developers and start >> thinking as translators, who use gui apps and reuse localisations. I >> find the lack of translator input into bodington very frustrating. > > Did most of the moodle translation get some by professional > translators? I'm guessing it was some french bloke who happened to > install it and found it easy to hack at a translation. I agree that > supporting professional translators is good but this is not the only > way to get an application translated. > > >> So if we have 500 templates all 500 TMX files would be loaded into >>> memory? >> ditto for property files >> There are two facets of the i18n process. One is internal, where each >> language template class harvests it's own language specific content >> and stores it in an internal representation, in the most efficient >> manner mangageable. The other is external, where humans are doing the >> translation work, most probably using tools designed specifically for >> the job. I think tmx files will suit both facets. > > I think it comes down to us seeing the translation being done > differently. > >> Although there may be 25 languages per template, times 500, that >> makes a lot of class files but they're only loaded into memory upon >> access. If the system supports 25 languages but only one is ever used >> then only one set of resources is ever loaded. > > But if all the languages are in one file then all the languages will > get loaded for each template. If we used ResourceBundles then only the > used languages would get loaded. > > Isn't adding TMX also adding more complexity. ResourceBundle is > reasonably bug free. Although I'm sure you'd write a good TMX > implementation it wouldn't have had the ammount of testing/tweaking > that ResourceBundle has. > > -- > +--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 Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Alistair Y. <ali...@sm...> - 2005-05-24 14:50:01
|
> Au contraire! I apologize for the somewhat sarcastic tone of some of > my previous posts phew, I thought you hated me! I'm very delicate you know. when I say template compilation is boken I don't really mean it's broken - they compile fine. It's just that the resource files won't be found. I'm moving the resource files to the classpath which will remove this issue. It won't, however, remove the problem of a user moving the webapp around but the templates would break if they did that, whether they were precompiled or compiled by bod. perhaps a FAQ entry on how to move bod to a new server/webapp root? first thing after moving is to delete the compiled templates. > It's just that it strikes me you should be discovering some of these > issues *before* committing rather than after yes, I agree. I'm just using the space between now and 2.6 to get as much in head as I can, without major merging, which I can't do as I have a multitude of other projects waiting to bite my bum ;) If I get any more curmudgeonly I'll be getting dragged behind the boat in my own dinghy. Alistair On 24 May 2005, at 15:29, Alexis O'Connor wrote: > Alistair Young wrote: >> I know i18n is an unpopular subject and it's seen as superfluous by >> some people, especially trying to retrofit it to an ancient system >> like this - if it's too much for some to bear I can always just stop? > > Au contraire! I apologize for the somewhat sarcastic tone of some of > my previous posts, but I'm actually entirely sympathetic to the notion > of being i18n compatible. It's just that it strikes me you should be > discovering some of these issues *before* committing rather than > after. > > Just as a general point of illumination, the template-compiler ANT > task (org.bodington.ant.TemplateBuilderTask) now supports the boolean > 'failonerror' attribute (making it more consistent with complementary > tasks such as Javac and JspC). By default this is true. Therefore, > where a broken template is template no. 300 of 500, the following 199 > are not even looked at. The whole build will fail as soon as a > template contains 'unrecoverable errors'. Setting failonerror to > 'false' means the build continues. If any templates contain > unrecoverable errors then a warning message is written to the console > saying how many fell into this category. > > > Alexis > > > P.S. Of course, the other alternative as the task is now an implicit > FileSet is to do something like the following :-) > > <template-compiler ... > > <include name="**/*.html" /> > <exclude name="**/templateGivingYouAgro.html" /> > </template-compiler> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Matthew B. <mat...@co...> - 2005-05-24 14:48:49
|
Alistair Young wrote: >> just concerned about the implementation > > what would you change? I'd just go with ResourceBundles. Is there any reason why we couldn't translate from TMX to ResourceBundles and back? -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Matthew B. <mat...@co...> - 2005-05-24 14:47:06
|
Alistair Young wrote: >> Why have I seen and used ResourceBundles before but never TMX? > > coz you (and I) are developers - there's a completely different world > out there, where translators translate, who have never heard of > programming language bindings such as ResourceBundle. But everyone (including translators) have head of files with: page.title=My Page [..snipped..] > The translation community is moving in a tmx direction, so I would think > it would be a good idea to shuffle along with them, if we want them to > localise our vle. I'm not at all convinced but hey, your the guy writing the code and I think we both understand each others point of view. Happy Hacking with TMX if you think that is the way to go. -- +--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-05-24 14:42:49
|
there's a new one in head - if you want to try it on windows - you'll need to delete any compiled templates first to get rid of the old problem this addresses. if those with windows machines could let me know if it helps... Alistair |
|
From: Matthew B. <mat...@co...> - 2005-05-24 14:42:09
|
I'm not saying Alistair Young wrote: >> What problems do you envisage? > > outside of classpath I have to worry about windows - do I have time? no! :-) >> Does this make it harder for people to be working on translations at >> the same time as someone has to merge the files back together > > not sure yet - tmx files are designed to be used with translation Properties files are also designed to be loaded into translation software and they are probably supported by more translation software than TMX. > applications rather than hand editors. Anyway, that's how cvs works. I > would think that users would donate translations to the community and we > would be responsible for merging them into the tree, just as we are for > code. Seems to be making more work for us. >> What do we gain? > > each template has only one resource file rather than, say 10 How is that better? >> What is wrong with the properties file approach? > > the biggest problem I've found is the fact that properties files are > meant for strings, not content. You can't have linebreaks in a > properties file value. As most web devs put these in to make it easier > to design, they'd have to remove them to localise the template. XML gets > round this problem. HTML translates all tabs, spaces and newlines into a space (unless inside a <pre>, I forget the CSS equivelent). >> Doesn't this mean someone has to have an understanding of XML > > not necessarily - we must stop thinking as developers and start thinking > as translators, who use gui apps and reuse localisations. I find the > lack of translator input into bodington very frustrating. Did most of the moodle translation get some by professional translators? I'm guessing it was some french bloke who happened to install it and found it easy to hack at a translation. I agree that supporting professional translators is good but this is not the only way to get an application translated. >> So if we have 500 templates all 500 TMX files would be loaded into >> memory? > > ditto for property files > > There are two facets of the i18n process. One is internal, where each > language template class harvests it's own language specific content and > stores it in an internal representation, in the most efficient manner > mangageable. The other is external, where humans are doing the > translation work, most probably using tools designed specifically for > the job. I think tmx files will suit both facets. I think it comes down to us seeing the translation being done differently. > Although there may be 25 languages per template, times 500, that makes a > lot of class files but they're only loaded into memory upon access. If > the system supports 25 languages but only one is ever used then only one > set of resources is ever loaded. But if all the languages are in one file then all the languages will get loaded for each template. If we used ResourceBundles then only the used languages would get loaded. Isn't adding TMX also adding more complexity. ResourceBundle is reasonably bug free. Although I'm sure you'd write a good TMX implementation it wouldn't have had the ammount of testing/tweaking that ResourceBundle has. -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Alexis O'C. <ale...@co...> - 2005-05-24 14:39:09
|
Alistair Young wrote: >> What problems do you envisage? > > outside of classpath I have to worry about windows - do I have time? no! > Problems concerning which way ones file seperators lean will probably go away with an alternative implementation anyway. But just for the record , using java.io.File in conjunction with java.net.URI to resolve and / or relative file paths can facilitate a catch-all solution across OS platforms. Alexis |
|
From: Alexis O'C. <ale...@co...> - 2005-05-24 14:30:02
|
Alistair Young wrote: > I know i18n is an unpopular subject and it's seen as superfluous by some > people, especially trying to retrofit it to an ancient system like this > - if it's too much for some to bear I can always just stop? Au contraire! I apologize for the somewhat sarcastic tone of some of my previous posts, but I'm actually entirely sympathetic to the notion of being i18n compatible. It's just that it strikes me you should be discovering some of these issues *before* committing rather than after. Just as a general point of illumination, the template-compiler ANT task (org.bodington.ant.TemplateBuilderTask) now supports the boolean 'failonerror' attribute (making it more consistent with complementary tasks such as Javac and JspC). By default this is true. Therefore, where a broken template is template no. 300 of 500, the following 199 are not even looked at. The whole build will fail as soon as a template contains 'unrecoverable errors'. Setting failonerror to 'false' means the build continues. If any templates contain unrecoverable errors then a warning message is written to the console saying how many fell into this category. Alexis P.S. Of course, the other alternative as the task is now an implicit FileSet is to do something like the following :-) <template-compiler ... > <include name="**/*.html" /> <exclude name="**/templateGivingYouAgro.html" /> </template-compiler> |
|
From: Matthew B. <mat...@co...> - 2005-05-24 14:23:15
|
Looks like SF have updated the statistics: http://sourceforge.net/project/stats/?group_id=87659&ugn=bodington -- +--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-05-24 14:22:53
|
> just concerned about the implementation what would you change? Alistair On 24 May 2005, at 15:07, Matthew Buckett wrote: > Alistair Young wrote: >> I know i18n is an unpopular subject and it's seen as superfluous by >> some people, especially trying to retrofit it to an ancient system >> like this - if it's too much for some to bear I can always just stop? > > Sorry if my posts come across as too negative. I am keen on getting > i18n in, just concerned about the implementation. > > -- > +--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 Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Alistair Y. <ali...@sm...> - 2005-05-24 14:20:45
|
> Why have I seen and used ResourceBundles before but never TMX? coz you (and I) are developers - there's a completely different world out there, where translators translate, who have never heard of programming language bindings such as ResourceBundle. Munging localised strings to internal representations is not even worth talking about, it's so trivial. The real work is in making it as easy as possible for translators to join the community. The translation community is moving in a tmx direction, so I would think it would be a good idea to shuffle along with them, if we want them to localise our vle. Alistair On 24 May 2005, at 14:50, Matthew Buckett wrote: > Alistair Young wrote: >>> having the ability to install Bod when running Tomcat with a JRE is >>> better >> ...than precompiling templates? Do you think we shouldn't precompile >> Mathew? > > Precompiling is better. It means someone can run Bodington without > having to download a JDK. > >>> I think is probably the way to go as it is the "standard" Java way >>> of loading i18n properties files >> yes, agreed. See my next email about TMX! > > Why have I seen and used ResourceBundles before but never TMX? > > -- > +--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 Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Alistair Y. <ali...@sm...> - 2005-05-24 14:17:15
|
> What problems do you envisage? outside of classpath I have to worry about windows - do I have time? no! > Does this make it harder for people to be working on translations at > the same time as someone has to merge the files back together not sure yet - tmx files are designed to be used with translation applications rather than hand editors. Anyway, that's how cvs works. I would think that users would donate translations to the community and we would be responsible for merging them into the tree, just as we are for code. > What do we gain? each template has only one resource file rather than, say 10 > What is wrong with the properties file approach? the biggest problem I've found is the fact that properties files are meant for strings, not content. You can't have linebreaks in a properties file value. As most web devs put these in to make it easier to design, they'd have to remove them to localise the template. XML gets round this problem. > Doesn't this mean someone has to have an understanding of XML not necessarily - we must stop thinking as developers and start thinking as translators, who use gui apps and reuse localisations. I find the lack of translator input into bodington very frustrating. > Wouldn't most people find the simple (inflexible) properties files > easier? I really don't know - I don't know what you mean by "people" - devs maybe - real translators? probably not. > So if we have 500 templates all 500 TMX files would be loaded into > memory? ditto for property files There are two facets of the i18n process. One is internal, where each language template class harvests it's own language specific content and stores it in an internal representation, in the most efficient manner mangageable. The other is external, where humans are doing the translation work, most probably using tools designed specifically for the job. I think tmx files will suit both facets. Although there may be 25 languages per template, times 500, that makes a lot of class files but they're only loaded into memory upon access. If the system supports 25 languages but only one is ever used then only one set of resources is ever loaded. Alistair On 24 May 2005, at 14:42, Matthew Buckett wrote: > Alistair Young wrote: >> I'm thinking of using TMX for a more robust localisation system, >> especially if we have to revert to CLASSPATH stuff. > > What problems do you envisage? > >> http://www.lisa.org/tmx/ >> Basically, each template would have it's own TMX file, which contains >> all available translations of it's strings. > > Does this make it harder for people to be working on translations at > the same time as someone has to merge the files back together. > >> Would be cleaner than separate language speciific Properties files. > > What do we gain? What is wrong with the properties file approach? > Doesn't this mean someone has to have an understanding of XML if they > are going to edit the file? Wouldn't most people find the simple > (inflexible) properties files easier? > >> I'd use SAX to keep the overhead down when loading the tmx files. >> Although each tmx contains all languages, only those that are used >> would be loaded into memory. > > So if we have 500 templates all 500 TMX files would be loaded into > memory? > > -- > +--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 Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Alexis O'C. <ale...@co...> - 2005-05-24 14:08:59
|
Peter Crowther wrote: >>From: Alexis O'Connor >>Whilst we're on the subject, a slightly rhetorical question, >>but do you >>reckon the method XmlTemplate::compileI18NConfig(Element) >>will work on >>Windows!?! > > > By observation (guess who develops on Windows 2000): No. Or at least > *something* in there is fouling up - still chasing. > > - Peter Peter, it really was a rhetorical question. I'm on XP and it doesn't ;-). If you run bodington in a servlet container, you can not access the user options page. The locale specific template e.g. style_default_default/template_useroptions_en.java will hardcode something like: String resourceFile = "C:\dev\eclipse\workspaces\3.1\bodington-HEAD\build\bodington\templates\style_default\default/lang/en/useroptions.properties"; This will not compile to bytecode. Presumably a *nix style relative path is being appended onto a Windows format file path. Alexis |
|
From: Matthew B. <mat...@co...> - 2005-05-24 14:07:39
|
Alistair Young wrote: > I know i18n is an unpopular subject and it's seen as superfluous by some > people, especially trying to retrofit it to an ancient system like this > - if it's too much for some to bear I can always just stop? Sorry if my posts come across as too negative. I am keen on getting i18n in, just concerned about the implementation. -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Matthew B. <mat...@co...> - 2005-05-24 14:01:43
|
Alistair Young wrote: > I'm thinking of using TMX for a more robust localisation system, > especially if we have to revert to CLASSPATH stuff. > > http://www.lisa.org/tmx/ On the rather dead implementation list, this thread is quite interesting: http://lists.lisa-open.org/archives/tmx_imp/200501/msg00000.html Seems to be saying that TMX is seen more as a way of moving translated data between systems, rather than being used directly. -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Matthew B. <mat...@co...> - 2005-05-24 13:50:15
|
Alistair Young wrote: >> having the ability to install Bod when running Tomcat with a JRE is >> better > > ...than precompiling templates? Do you think we shouldn't precompile > Mathew? Precompiling is better. It means someone can run Bodington without having to download a JDK. >> I think is probably the way to go as it is the "standard" Java way of >> loading i18n properties files > > yes, agreed. See my next email about TMX! Why have I seen and used ResourceBundles before but never TMX? -- +--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-05-24 13:45:47
|
> Or even, i18n breaks template compilation well, hardly > However, your "contributions" are demonstrating very clearly why it is > desirable to valaidate the templates I know i18n is an unpopular subject and it's seen as superfluous by some people, especially trying to retrofit it to an ancient system like this - if it's too much for some to bear I can always just stop? > do you reckon the method XmlTemplate::compileI18NConfig(Element) will > work on Windows! of course not but there is time before 2.6 - I am getting there... Alistair On 24 May 2005, at 14:20, Alexis O'Connor wrote: > Alistair Young wrote: >> It seems that when you pre-compile the templates, it breaks i18n. > > Or even, i18n breaks template compilation. > >> There are two ways round this: >> 1) Don't pre-compile templates - bod can do it anyway >> 2) I change i18n to put resource files in the classpath so the full >> path isn't required. That means the resource files will be separate >> from the templates and we'll need a new WEB-INF/classes directory >> where one didn't exist before. >> anyone got any opinions? > > Er, point (1) is quite true. However, your "contributions" are > demonstrating very clearly why it is desirable to valaidate the > templates prior to deployment(!). In addition to validation up until > now we've had pre-compilation too - i.e. generate all the templates > and then you can even run Bodington on a JRE. Therefore, put the > resource files on the CLASSPATH, and as you say, probably under > 'WEB-INF/classes'. > > Whilst we're on the subject, a slightly rhetorical question, but do > you reckon the method XmlTemplate::compileI18NConfig(Element) will > work on Windows!?! > > > Alexis > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Matthew B. <mat...@co...> - 2005-05-24 13:43:03
|
Alistair Young wrote: > I'm thinking of using TMX for a more robust localisation system, > especially if we have to revert to CLASSPATH stuff. What problems do you envisage? > http://www.lisa.org/tmx/ > > Basically, each template would have it's own TMX file, which contains > all available translations of it's strings. Does this make it harder for people to be working on translations at the same time as someone has to merge the files back together. > Would be cleaner than separate language speciific Properties files. What do we gain? What is wrong with the properties file approach? Doesn't this mean someone has to have an understanding of XML if they are going to edit the file? Wouldn't most people find the simple (inflexible) properties files easier? > I'd use SAX to keep the overhead down when loading the tmx files. > Although each tmx contains all languages, only those that are used would > be loaded into memory. So if we have 500 templates all 500 TMX files would be loaded into memory? -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
|
From: Peter C. <Pet...@me...> - 2005-05-24 13:40:18
|
> From: Alexis O'Connor=20 > Whilst we're on the subject, a slightly rhetorical question,=20 > but do you=20 > reckon the method XmlTemplate::compileI18NConfig(Element)=20 > will work on=20 > Windows!?! By observation (guess who develops on Windows 2000): No. Or at least *something* in there is fouling up - still chasing. - Peter |
|
From: Alistair Y. <ali...@sm...> - 2005-05-24 13:24:29
|
> having the ability to install Bod when running Tomcat with a JRE is > better ...than precompiling templates? Do you think we shouldn't precompile Mathew? > I think is probably the way to go as it is the "standard" Java way of > loading i18n properties files yes, agreed. See my next email about TMX! Alistair On 24 May 2005, at 14:04, Matthew Buckett wrote: > Alistair Young wrote: >> It seems that when you pre-compile the templates, it breaks i18n. >> This is due to the local build path being used to initialise the >> resource file paths: >> WEB-INF/template_classes/working/style_default_default/ >> template_useroptions.java: >> String resourceFile = >> "/Users/alistair/dev/sourceforge/Bodington/build/bodington/templates/ >> style_default/default/lang/null/useroptions.properties"; >> this is never going to work as resourceFile as defined above doesn't >> exist when you deploy. >> it works if you don't compile the templates and let bodington compile >> them itself as and when needed. > > This does cause another problem though, if someone is running tomcat > and bodington in the directory /usr/local/tomcat and decides to move > tomcat to /home/tomcat then all the templates stop working. > >> There are two ways round this: >> 1) Don't pre-compile templates - bod can do it anyway > > I'd say that if we are trying to make Bodington as easy as possible to > install having the ability to install Bod when running Tomcat with a > JRE is better. > >> 2) I change i18n to put resource files in the classpath so the full >> path isn't required. That means the resource files will be separate >> from the templates and we'll need a new WEB-INF/classes directory >> where one didn't exist before. > > I think is probably the way to go as it is the "standard" Java way of > loading i18n properties files. > We don't need to have the files expanded under WEB-INF/classes, it > just makes things easier for people who want to do translation. > >> anyone got any opinions? > > Silly question ;-) > > -- > +--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 Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Alistair Y. <ali...@sm...> - 2005-05-24 13:21:47
|
I'm thinking of using TMX for a more robust localisation system, especially if we have to revert to CLASSPATH stuff. http://www.lisa.org/tmx/ Basically, each template would have it's own TMX file, which contains all available translations of it's strings. Would be cleaner than separate language speciific Properties files. I'd use SAX to keep the overhead down when loading the tmx files. Although each tmx contains all languages, only those that are used would be loaded into memory. seem ok? Alistair |
|
From: Alexis O'C. <ale...@co...> - 2005-05-24 13:20:48
|
Alistair Young wrote: > It seems that when you pre-compile the templates, it breaks i18n. > Or even, i18n breaks template compilation. > There are two ways round this: > > 1) Don't pre-compile templates - bod can do it anyway > 2) I change i18n to put resource files in the classpath so the full > path isn't required. That means the resource files will be separate > from the templates and we'll need a new WEB-INF/classes directory where > one didn't exist before. > > anyone got any opinions? Er, point (1) is quite true. However, your "contributions" are demonstrating very clearly why it is desirable to valaidate the templates prior to deployment(!). In addition to validation up until now we've had pre-compilation too - i.e. generate all the templates and then you can even run Bodington on a JRE. Therefore, put the resource files on the CLASSPATH, and as you say, probably under 'WEB-INF/classes'. Whilst we're on the subject, a slightly rhetorical question, but do you reckon the method XmlTemplate::compileI18NConfig(Element) will work on Windows!?! Alexis |
|
From: Matthew B. <mat...@co...> - 2005-05-24 13:04:14
|
Alistair Young wrote: > It seems that when you pre-compile the templates, it breaks i18n. > > This is due to the local build path being used to initialise the > resource file paths: > > WEB-INF/template_classes/working/style_default_default/ > template_useroptions.java: > > String resourceFile = > "/Users/alistair/dev/sourceforge/Bodington/build/bodington/templates/ > style_default/default/lang/null/useroptions.properties"; > > this is never going to work as resourceFile as defined above doesn't > exist when you deploy. > > it works if you don't compile the templates and let bodington compile > them itself as and when needed. This does cause another problem though, if someone is running tomcat and bodington in the directory /usr/local/tomcat and decides to move tomcat to /home/tomcat then all the templates stop working. > There are two ways round this: > > 1) Don't pre-compile templates - bod can do it anyway I'd say that if we are trying to make Bodington as easy as possible to install having the ability to install Bod when running Tomcat with a JRE is better. > 2) I change i18n to put resource files in the classpath so the full > path isn't required. That means the resource files will be separate > from the templates and we'll need a new WEB-INF/classes directory where > one didn't exist before. I think is probably the way to go as it is the "standard" Java way of loading i18n properties files. We don't need to have the files expanded under WEB-INF/classes, it just makes things easier for people who want to do translation. > anyone got any opinions? Silly question ;-) -- +--Matthew Buckett-----------------------------------------+ | VLE Developer, Learning Technologies Group | | Tel: +44 (0) 1865 283660 http://www.oucs.ox.ac.uk/ | +------------Computing Services, University of Oxford------+ |
19 messages has been excluded from this view by a project administrator.
