Re: [dev-biblio] localization?
On Thursday 06 July 2006 11:47 pm, Bruce D'Arcus wrote: > I wonder if the easy way to do this is to remove all strings from CSL > files, define a list of variables, and allow them to be implemented > natively in software? That way the files are mostly simplified, and > remain self-contained. Doing that, I could also move the prefix and > suffix elements back to attributes, since they don't have to carry any > formatting information. Files become more compact, and any possible > future OO code is simpler (prefix and suffix become simple attributes > of an object, rather than full objects). >So thinking not in XML, but rather YAML ... snip ... > > I hadn't done this earlier because I thought it wasn't possible, but > maybe I'm wrong. > > Would that work? I think it would. It looks neat and is simpler to manage than my idea of the using macro processing to achieve the same thing The tables of english->'other language' strings could easily be added to list of task the international language translators need to work on. david > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- --- David N. Wilson Co-Project Lead for the Bibliographic OpenOffice Project http://bibliographic.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] localization?
I wonder if the easy way to do this is to remove all strings from CSL files, define a list of variables, and allow them to be implemented natively in software? That way the files are mostly simplified, and remain self-contained. Doing that, I could also move the prefix and suffix elements back to attributes, since they don't have to carry any formatting information. Files become more compact, and any possible future OO code is simpler (prefix and suffix become simple attributes of an object, rather than full objects). So thinking not in XML, but rather YAML, it could be as simple as this: en: in: In and: and accessed: accessed date-accessed: date accessed presented-at: presented at editor-single-full: Editor editor-multiple-full: Editors editor-single-short: Ed editor-multiple-short: Eds edited-by: Edited By translator-single-full: Translator translator-multiple-full: Translators translator-single-short: Tran translator-multiple-short: Trans translated-by: Translated By The style file would then just be responsible for selecting the right variables; something like: I hadn't done this earlier because I thought it wasn't possible, but maybe I'm wrong. The software would then know which specific variable to grab depending on, for example, the role and whether there is one or more. In code: def print_role(role, type, form, single) case role when "editor" if type == "noun" and form == "short" and single == true then puts @@strings["en"]["editor-short"] end end end Not the best code, but you get the idea. Would that work? Bruce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] localization?
On Jul 5, 2006, at 8:58 PM, James Howison wrote: It occurs to me that one risk of not factoring out the language specific aspects is that changes or improvements made in the 'base styles' don't cascade to the other languages, leaving them to bit-rot, especially if some non-compatible change is made. Hmm ... good point James. OTOH, if the complexity increase of maintaining them linked to the main style, then that becomes a blocker too (and potentially a more serious one, at least from my english-centric PoV). I think Matthias and I managed to figure out the more difficult things, and I'll see if I can't figure out a way to do it fairly painlessly. Bruce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] localization?
It occurs to me that one risk of not factoring out the language specific aspects is that changes or improvements made in the 'base styles' don't cascade to the other languages, leaving them to bit- rot, especially if some non-compatible change is made. OTOH, if the complexity increase of maintaining them linked to the main style, then that becomes a blocker too (and potentially a more serious one, at least from my english-centric PoV). --J On Jul 5, 2006, at 7:02 PM, David Wilson wrote: My guess is that for the final production version that would eventually ship with OpenOffice, would need need either separate language versions of the CSL files or internationalization via the use strings in a separate files. In styles like Chicago there are a few language specific strings like "Publisher not known". Although I do not know enough styles to know if this is the case with all of them If as you say using lookup language strings makes the csl files to0 complex, then producing separate language versions may not be as difficult as it may first seem. This can be done through macro processors or other conversion tools. This could made easier if the csl files could include a indicator for the strings that may need language conversion. Using this approach the user can modify their own standalone csl files, and can even share them on web site as we have discussed before. David On Thursday 06 July 2006 2:29 am, Bruce D'Arcus wrote: I think it's time to move this to the relevant lists: Awhile back I made the decision (after soliciting comments) that all CSL files would be language-specific. I did this because in the real world of academic publishing (which is really the target) styles are almost by definition language-specific. One does not typically use more generic styles like APA or Chicago, but publisher or journal specific variations, each of which are aimed at a particular target audience and language. Matthias Steffens has suggested I allow for optional internationalization extensions, so that if a non-english user, say, was using the "apa" style (defined in english), it would lookup the strings in a separate file. My worry about this approach is it adds needless complexity (flles are more complex, no longer self-contained, etc.), for unclear benefit. Yes, in some cases it will result in redundancy and duplication, but does that really matter in this case? I can get into specifics if needed, but thought I'd start with the basic question of requirements/use case. 1) Do we care about localization within styles? Should a user be able to define (and choose) a style independent of language? 2) Is it important that style files be self-contained? Anything else? Bruce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: dev- [EMAIL PROTECTED] -- --- David N. Wilson Co-Project Lead for the Bibliographic OpenOffice Project http://bibliographic.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] localization?
My guess is that for the final production version that would eventually ship with OpenOffice, would need need either separate language versions of the CSL files or internationalization via the use strings in a separate files. In styles like Chicago there are a few language specific strings like "Publisher not known". Although I do not know enough styles to know if this is the case with all of them If as you say using lookup language strings makes the csl files to0 complex, then producing separate language versions may not be as difficult as it may first seem. This can be done through macro processors or other conversion tools. This could made easier if the csl files could include a indicator for the strings that may need language conversion. Using this approach the user can modify their own standalone csl files, and can even share them on web site as we have discussed before. David On Thursday 06 July 2006 2:29 am, Bruce D'Arcus wrote: > I think it's time to move this to the relevant lists: > > Awhile back I made the decision (after soliciting comments) that all > CSL files would be language-specific. I did this because in the real > world of academic publishing (which is really the target) styles are > almost by definition language-specific. One does not typically use more > generic styles like APA or Chicago, but publisher or journal specific > variations, each of which are aimed at a particular target audience and > language. > > Matthias Steffens has suggested I allow for optional > internationalization extensions, so that if a non-english user, say, > was using the "apa" style (defined in english), it would lookup the > strings in a separate file. > > My worry about this approach is it adds needless complexity (flles are > more complex, no longer self-contained, etc.), for unclear benefit. > Yes, in some cases it will result in redundancy and duplication, but > does that really matter in this case? > > I can get into specifics if needed, but thought I'd start with the > basic question of requirements/use case. > > 1) Do we care about localization within styles? Should a user be able > to define (and choose) a style independent of language? > > 2) Is it important that style files be self-contained? > > Anything else? > > Bruce > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- --- David N. Wilson Co-Project Lead for the Bibliographic OpenOffice Project http://bibliographic.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
