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.
This quite similar to what is used to localize Cocoa applications.
** 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 
- 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).- Then when a localized text is needed a call to a function is made
with the string as parameter.- The function determines the current language, looks for the
associated file (such as nl.loc, de.loc, etc.).*- 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.
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.
I guess it boils down to this:
one kind of file: a CSL file:
two kind of files: a CSL file and a localization file:
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