new purls

FYI, I just registered some purls for the namespaces:

The current bib prefix should now be changed to bind to
http://purl.org/NET/xbiblio/citeproc
Likewise, the current cs prefix should now bind – and the
citation-style schema needs to be changed – to
http://purl.org/NET/xbiblio/csl.

Bruce

Hello Bruce and others,

I am trying to read through the xslt stuff. I noticed that text such as
"Anonymous" is hard coded. Wouldn’t it be better to use a function that
looks up the text in a file.

  1. From the DocBook (or whatever the source) the language of the text is
    obtained, or the user specifies it in a parameter (less desirable, but
    would be nice to allow).
  2. Then when a localized text is needed a call to a function is made
    with the string as parameter.
  3. The function determines the current language, looks for the
    associated file (such as nl.loc, de.loc, etc.).*
  4. and then searches the file for the string. The file holds the
    non-localized (English) and the localized string as a pair, the function
    then returns the localized one. **

This quite similar to what is used to localize Cocoa applications.

  • It’s better to use a folder with a separate file for each language as
    those files most likely has to be dealt with by several different
    persons. There are standards for language abbreviations, which can be
    used here.

** It’s better to use English as the non-localized string instead of
some kind of identifier. If the loc files misses a localized counterpart
the English one can be used. It would be handy to have a en.loc in there
too, if only as a start point for translations.

I suppose that this can be done with xslt?

Now I’ll continue reading the xslt stuff to gain better understanding of
the whole thing…

Regards,

Johan Kool

I am trying to read through the xslt stuff. I noticed that text such
as “Anonymous” is hard coded. Wouldn’t it be better to use a function
that looks up the text in a file.

Yes. There’s a lot of stuff in there that is not as clean as it should
be :wink:

  1. From the DocBook (or whatever the source) the language of the text
    is obtained, or the user specifies it in a parameter (less desirable,
    but would be nice to allow).
  2. Then when a localized text is needed a call to a function is made
    with the string as parameter.
  3. The function determines the current language, looks for the
    associated file (such as nl.loc, de.loc, etc.).*
  4. and then searches the file for the string. The file holds the
    non-localized (English) and the localized string as a pair, the
    function then returns the localized one. **

Wouldn’t it be easier to handle all localization in the CSL style files?

Take a look and see what you think. The idea I settled on is that
those files are language specific. So we could add necessary features
there.

I have on the TODO, for example, the question about whether month
representation ought to be handled there.

Bruce

Let me see what you think Johan. Here’s what I propose as one way to
handle localization of the thing you mentioned, and of dates.

Here’s a complete CSL file, with added content indicated with a suffix. Think of a) what will work in this context, and b) how
it would translate to a GUI editor.

<?xml version="1.0" encoding="utf-8"?>



author-year

Bruce D’Arcus

2004-07-30

Chicago
15

geography
sample style file for author-year class





Jan
Feb
Mar
Apr
May
Jun
July
Aug
Sept
Oct
Nov
Dec






Ed.
Eds.




tran.
trans.





PhD Dissertation


letter




CD-ROM




(



,



:


)











(
)



,




:



,


(
)



,


,













(
)






, In





,



(


:

)

















(
)



,



,








,



(
)





,


(
),


available from:

,


,





</citationstyle

Doesn’t this have the disadvantage of having to do the translation for
every citation style again and again? Until now there are only a few,
in the end every journal could have its own.* Plus you are multiplying
the number of files needed. This way you need number of styles × number
of languages instead of number of styles + number of languages.

  • In fact most journals only publish in one language anyway, so perhaps
    that can be used as an argument for one file suggestion.

I guess it boils down to this:

one kind of file: a CSL file:

  • very fine grained control
  • many files
  • many translations that are exactly alike

two kind of files: a CSL file and a localization file:

  • less files
  • centralized translations
  • less control

For the last one: one journal might want to read: Anonymous and another
may want Author unknown

I am not yet sure which of these two approaches is the best one…

Johan

Doesn’t this have the disadvantage of having to do the translation for
every citation style again and again?

Yes. Each style is simpler, but there are more of them.

Until now there are only a few, in the end every journal could have
its own.*

Yes. The Endnote repository has something like 1,400.

Plus you are multiplying the number of files needed. This way you need
number of styles × number of languages instead of number of styles +
number of languages.

  • In fact most journals only publish in one language anyway, so
    perhaps that can be used as an argument for one file suggestion.

Exactly. The only styles likely to have more than one language are
core styles like Chicago. I am an American, but if I publish in a
British journal, I need to use British spelling. So, one style file.

I guess it boils down to this:

one kind of file: a CSL file:

  • very fine grained control
  • many files
  • many translations that are exactly alike

Scripts and GUIs can make the above easier though. For example, the
“basedOn” fields can be used to auto-fill a new style.

Another advantage, though, is — again – it’s simpler. Imagine if
you had to edit or create a style file in a GUI, and had to manage 20
languages at once. There are other places where language comes in;
places where you can’t necessarily localize it reliably across styles.
For example, if you have a url, then you often do “available at” or
whatever. If you have multiple language support within a style file,
you could end up with REALLY long and complex style documents.

We had this discussion on the OpenOffice bib dev list, and we sort of
concluded that single-language/style file is better. It wasn’t an
overwhelming position, though.

Bruce