Menu
▾
▴
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: 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: 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: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: 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: 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: Matthew B. <mat...@co...> - 2005-05-24 15:38:01
|
Alistair Young wrote: >> 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 was meaning that you don't need the newlines in there, in the HTML world a space is the same. [..snipped..] > I mentioned tmx to test the water. It's cutting edge and groovy, yes. I'm an old fart, already listening to Radio 4 with a pair of tartan slippers, stuck in my ways ;-) [..snipped..] > what about xml properties files sitting in the classpath, one per > template, per language? If you like. I think I'm not yet convinced that anything is better than the ResouceBundle but at the end of the day it should be quite easy to move from one way of representing translations to another so happy hacking. -- +--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------+ |
×
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