Finnish language citation style (for Word)?

Hello!

I hope my question is trivial. I need to instruct students about Zotero and citation styles for Word in Finnish. Well, after quick try and a bit searching I came up with nothing concrete except that this should be possible to do.

I changed my language in Firefox to Finnish (quick locale switcher) but nothing changed in citations :) – that was as expected I guess, but now I don’t know what to do next?

Any pointers?
  • Some styles have hard-coded locale values, so might not work.

    Set the Firefox language to Finnish and use the APA style and you will get Finnish bibliography.

    See also:

    http://forums.zotero.org/discussion/27171/nametext-change-to-og/#Item_9
  • edited January 13, 2013
    Ty, but I can't make it work. I think the problem initially (not sure though) was that language switcher changed the key to 'fi', not to 'fi-FI’.

    There is always some part in English or a bit wrong. Examples:
    APA:
    Zotero - Wikipedia, the free encyclopedia. (n.d.). Noudettu tammikuu 13, 2013, alkaen http://en.wikipedia.org/wiki/Zotero

    IEEE:
    [1] “Zotero - Wikipedia, the free encyclopedia”. [Online]. Available: http://en.wikipedia.org/wiki/Zotero. [Accessed: 13-tammi-2013].

    What are my choices? Is it easy to make a style (only a style) with correct language format?
  • EDIT: In IEEE style, it seems I just need to change hard-coded words to Finnish, right?
  • The problem is that the localization files for Finnish do not seem to be very good. In the APA style, citing the source URLs is specified on lines 143-144. It says that "Take term 'from' the localization file and print it. Then print the URL".

    https://github.com/citation-style-language/styles/blob/master/apa.csl

    The localization term 'from' is defined as 'alkaen' on line 37.

    https://github.com/citation-style-language/locales/blob/master/locales-fi-FI.xml

    There are two ways to fix the issue
    1) Fix the localization files
    2) Choose a style and make a modified version where you hard code it into Finnish. Just changing the words may not do it because

    If you want to hard code a word instead of using term, you would need to change also the attribute name in the text element. So for example change



    to



    http://citationstyles.org/downloads/specification.html#text



    I am a Finn too so I have some interest in getting this to work. Particularly the APA style. I believe that the localization files are distributed with Zotero, so any fix would be automatically available to all users when the next version comes out.
  • I believe that the localization files are distributed with Zotero, so any fix would be automatically available to all users when the next version comes out.
    that's correct. Help improving locales is much appreciated and doesn't take much (really - any) programming skill.
  • I could actually take a shot at the localization file now that I have it open here.
  • So looking at the examples, would these be correct

    APA:
    Zotero - Wikipedia, the free encyclopedia. (n.d.). Noudettu tammikuu 13, 2013, alkaen http://en.wikipedia.org/wiki/Zotero

    Fixed version

    Zotero - Wikipedia, the free encyclopedia. (n.d.). Noudettu 13. tammikuuta 2013, osoitteesta http://en.wikipedia.org/wiki/Zotero

    I do not know how n.d. should be translated. e.p. (from the long form 'ei päivämäärää') does not sound right.

    The IEEE style has the texts hard coded although they do exist in the localization file, so that is why you are seeing these problems.
  • I'll try to fix this in IEEE asap.

    IIRC we can't currently properly localize dates in APA because of the way disambiguation works.
  • edited January 13, 2013
    @adamsmith: it might be possible to change the logic in citeproc-js to always append the year-suffix after the year in dates, so we can use a single cs:date element. Do you know of any exceptions? (e.g., cases where you need "2002-10-30a" instead of "2002a-10-30")?
  • There is one additional problem in the APA style. The "from" term in Finnish would be different for online sources and other sources. (e.g lines in 112 and 120 in the APA style)

    So for line 120, the text element should return "osoitteesta" (from address) and for 112 the from should be a suffix to what ever is stored in the archive variable.

    I do not think that the archive "from" can be really programmed correctly because of the complexity of the language.
  • Why is the date format hard coded in the APA syle?

    <text term="retrieved" text-case="capitalize-first" suffix=" "/>
    <group>
    <date variable="accessed" suffix=", ">
    <date-part name="month" suffix=" "/>
    <date-part name="day" suffix=", "/>
    <date-part name="year"/>
    </date>
    </group>

    The Finnish version of the style is day month year. Is this the disambiguation issue that you are referring to?

    In anycase, a fixed localization file for Finnish is now available at

    https://gist.github.com/4525723
  • edited January 13, 2013
    The Finnish version of the style is day month year. Is this the disambiguation issue that you are referring to?
    yes.

    @Rintze - yes, that should work. I've never seen disambiguation anywhere except after the year.
  • Note that the fixes in the date localization make only sense if the date order is fixed to day month year. Otherwise the existing is better. (It is incorrect, but less incorrect than the new version)
  • http://citationstyles.org/downloads/specification.html#localized-date-formats

    the order of date parts can be defined individually for every language.

  • the order of date parts can be defined individually for every language.
    Yes. The localization file for Finnish defines this correctly. However, as I pointed out above, the order is hard-coded in the APA style. Therefore, the citations will be incorrect.

    The correct way to cite dates would be
    14. tammikuuta 2013

    The APA style with the old localization file results in
    tammikuu 14, 2013

    The new localization file results in
    tammikuuta 14, 2013

    Both are wrong, but the latter is more wrong.
  • ah, OK, I didn't understand that correctly, makes sense now.
    @Rintze - if Frank is OK with that this could just be implemented in citeproc without a spec change, could it?
  • I've looked into this a little further. The CSL spec currently dictates: "By default the year-suffix is appended to the cite, and to the first year rendered through cs:date in the bibliographic entry, but its location can be controlled by explicitly rendering the "year-suffix" variable using cs:text. If "year-suffix" is rendered through cs:text in the scope of cs:citation, it is suppressed for cs:bibliography, unless it is also rendered through cs:text in the scope of cs:bibliography, and vice versa."

    citeproc-js implements this correctly. The problem in APA is that cs:citation uses cs:text to render the "year-suffix" variable. This suppresses the automatic year-suffix placement (which would normally automatically appear after the year, as per APA style), and creates the need to break up the "issued" date in two cs:date elements to insert the "year-suffix" variable with cs:text.

    @adamsmith, @fbennett, does either one of you know of any cases where the year-suffix needs to be suppressed in either the cite or bibliographic entry? Eliminating this suppression logic (the last quoted sentence above) would solve the issue.
  • Also, I'm not totally sure the logic for cites ("By default the year-suffix is appended to the cite,") makes the most sense. Wouldn't it be preferably to:

    1) place the year-suffix after the first year in the cite, as is done for cs:bibliography
    2) when no date is rendered, place it after the "no date" term, if used
    3) only when neither a date or the "no date" term is rendered, place the year-suffix at the end of the cite

    I'm thinking mostly of styles that use locators. For these, you'd normally want the year-suffix after the date, not at the end of the cite, right?
  • I'm thinking mostly of styles that use locators. For these, you'd normally want the year-suffix after the date, not at the end of the cite, right?
    definitely.

    Do I remember correctly that we have the year-suffix hard-coded into the style to correctly deal with the no date term or was there another reason?

    If so, Rintze's proposal would fix this and we could remove the hard-coding from APA style?

    I think it'd be nice to leave the suppress option in there, mainly because I like to keep CSL flexible, who knows what style guides come up with...
  • I think that the reason why the APA CSL style explicitly targets the year-suffix is to prevent it from showing up at the end of the cite, after the locator. Frank might know (see https://github.com/citation-style-language/styles/commit/e04205d7a6f1eb7290313512dfcfb11f2cf0f7a7 ).

    Regarding the need for suppression: what good is an disambiguation key if it's only used in one place?
  • for some reason, the suffix didn't print at all:
    Here's the context, but I can't really make sense of it
    http://forums.zotero.org/discussion/18967/1/error-year-disambiguation-in-authordate-styles/
    it'd be great if Frank could help.
  • I've read through the discussion, and I have at least a loose grasp on the issue. Making implicit year-suffix insertion more intelligent would be pretty cumbersome, and where it was needed to get a language working correctly with APA-like styles, we would lose the ability to format the suffix, which was the reason for introducing the variable in the first place.

    Would it help to extend CSL to permit the suffix to be included in the date spec in the locale area?
  • edited January 15, 2013
    I found an old off-list chat with Frank, and the reason for adding the year-suffix elements to APA was that there needs to be a hyphen between the "no date" term and the year-suffix (e.g., "Doe. (n.d.-a)"). In citeproc-js, this suppresses the year-suffix that is normally inserted within the "issued" date, requiring explicit use of the "year-suffix" variable there as well.

    I see two solutions:
    1) as Frank suggests, allow the year-suffix to be defined within cs:date. This can be done relatively simply from a CSL standpoint by treating it as date-part, e.g.:

    <date variable="issued">
    <date-part name="year"/>
    <date-part name="year-suffix" font-style="italic"/>
    <date-part name="month" prefix=", "/>
    <date-part name="day" prefix=" " />
    </date>


    The downside is that this needs a CSL schema update and adds a tiny bit of complexity to CSL.

    2) Change the year-suffix suppression behavior. Because of the need for the hyphen in case of "no date", the year-suffix needs to be explicitly defined within cs:citation at least once. But I'm wondering if we could:

    - leave the implicit year-suffix insertion behavior alone (although I think it would make sense to automatically append the year-suffix after the "no date" term)
    - completely disable year-suffix suppression (do we really need it?), even within cs:citation and cs:bibliography.

    This would only require a modification to the spec and the CSL processor. Frank, is there a need for year-suffix suppression that I'm not seeing?
  • I may be missing something here, but is the issue really that complex?

    The Finnish localization does not work properly because the data part order is hard coded for the "accessed" variable on lines 137-141 in the APA csl file.

    <date variable="accessed" suffix=", ">
    <date-part name="month" suffix=" "/>
    <date-part name="day" suffix=", "/>
    <date-part name="year"/>
    </date>

    Why couldn't the problem be solved simply by modifying the style so that the date format is retrieved from the localization file?

    <date variable="accessed" form="text" suffix=", ">
  • @mronkko, yes, we can do that. I'm just rather interested in seeing whether we can also localize the "issued" date variable, so all dates localize.
  • If Mikko's solution will serve in the short term I'm all +1 for that!

    On year-suffix suppression, I think at the moment the processor sniffs the style for any explicit year-suffix when it is first installed, and turns off the implicit behaviour globally if one is found. It should be doable to turn it off only under the specific node (cs:citation or cs:bibliography) where it is found. Would that be sufficient? More fine-grained behaviour (i.e. suppression only where there is an explicit year-suffix sibling) would be hard to do.

    Daydreaming about a CSL-based solution, something like:
    <date form="text">
    <date-part name="month" suffix=" "/>
    <date-part name="day" form="numeric-leading-zeros" suffix=", "/>
    <date-part name="year">
    <year-suffix/>
    </date-part>
    </date>

    might be easier to implement, because it would make the association of the year-suffix with the year element explicit.
  • Re year-suffix and the no-date term, I would be a little reluctant to apply the suffix implicitly. It requires a different join (an implicit hyphen in most cases, I guess), and style authors might be confused about where the joining character comes from, and how it can be controlled.
  • edited January 16, 2013
    About your daydream: but we don't have anything like in the schema (outside of cs:date we treat "year-suffix" as a variable that needs to be called via cs:text, and no other variable or term has its own element). (shudders)

    About suppression: to avoid changes to the CSL schema and solve the issue, the CSL processor needs to render the "year-suffix" variable explicitly where called through cs:text, or, if it is not, render it implicitly (we would then have an explicit "year-suffix" for the "no date" term, and rely on implicit rendering for the "issued" date variable). This test should probably be done independently for cs:citation and cs:bibliography (although in practice that might not matter; if there is no date for the cite, there won't be one for the bibliographic entry).

    I'll localize the other dates in APA, if that's the preferred mid-term solution.

This is an old discussion that has not been active in a long time. Before commenting here, you should strongly consider starting a new discussion instead. If you think the content of this discussion is still relevant, you can link to it from your new discussion.

Sign In or Register to comment.