localization?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

localization?

Bruce D'Arcus
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: localization?

David Wilson-7
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: [hidden email]
> For additional commands, e-mail: [hidden email]

--
-------------------
David N. Wilson
Co-Project Lead for the Bibliographic
OpenOffice Project
http://bibliographic.openoffice.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: localization?

James Howison
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: [hidden email]
>> For additional commands, e-mail: dev-
>> [hidden email]
>
> --
> -------------------
> David N. Wilson
> Co-Project Lead for the Bibliographic
> OpenOffice Project
> http://bibliographic.openoffice.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: localization?

Bruce D'Arcus

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: localization?

Bruce D'Arcus
In reply to this post by James Howison

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:

<accessed>
    <date>
       <label position="before"/>
    </date>
    <url/>
</accessed>
<roles>
    <label text-transform="lowercase"
                suffix=". "
                type="noun"
                form="short"
                position="before-unless-author"/>
</roles>

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: localization?

David Wilson-7
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: [hidden email]
> For additional commands, e-mail: [hidden email]

--
-------------------
David N. Wilson
Co-Project Lead for the Bibliographic
OpenOffice Project
http://bibliographic.openoffice.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]