APA 6th edition & Computer Program entries

adlerhn

In the APA 6th edition citation style, entries for computer programs should include the version number. More info: http://www.ltu.se/cms_fs/1.78649!/file/APA_6th_ed.pdf , https://owl.english.purdue.edu/owl/resource/560/25/ , http://www.lib.usm.edu/help/style_guides/apa.html

Jones, D. F. (2002). The citation analyzer (Version 3.2) [Computer software]. Fort Lauderdale, FL: Nova Southeastern University. Retrieved from http://www.buros.com/

However, the version is currently not being printed:

Williams, T., & Kelley, C. (2012). Gnuplot. Retrieved from http://www.gnuplot.info/

adamsmith

The style is now fixed. The updated version will appear on the repository within 30mins (check the timestamp). Update your copy of the style by re-installing it from the repository. (See here if you need instructions for installing styles in standalone.)

Styles should also update automatically within 24hs for Zotero 4.0+
In an existing document, you may have to switch to a different style and back for the changes to take effect once the style is updated.
Any further problems please let us know.

It will still not say [Computer software], though.

adlerhn

It works great, thanks a lot!

I don't know if the [Computer software] (which I personally dislike) is part of the APA 6th specification, as I haven't seen the actual specification, only a few samples and guides by some universities.

adamsmith

yeah, it's in the Manual (p. 210-211) but we have no good way of implementing it. I agree it's ugly, but that doesn't help us much ;)

adlerhn

On the implementation side, wouldn't it be so easy as to add the string in the csl file? I.e.:

      <else-if type="book graphic  motion_picture report song manuscript speech" match="any">
        <!---This is a hack until we have a computer program type -->
        <choose>
          <if variable="version">
            <group delimiter=" ">
              <text variable="title"/>
              <group delimiter=" " prefix="(" suffix=") [Computer program]">
                <text term="version" text-case="capitalize-first"/>
                <text variable="version"/>
              </group>
            </group>
          </if>
          <else>
            <text variable="title" font-style="italic"/>
          </else>
        </choose>
      </else-if>

I just tested this in the Reference Test Pane (chrome://zotero/content/tools/csledit.xul), and apparently works fine.

Sorry if I am doing something terribly wrong here, I am totally new to Zotero and CSL.

adamsmith

generally this is the right idea and you can do this for your own use, but the APA style is used in multiple languages and I really would like to avoid hard-coding English words into it (see how we use "version" as a term, for example - those are translated in several dozen languages, so the same style can be used in all of them).

adlerhn

Very interesting... Thanks! :)

aurimas

I came across a similar issue with annual reviews style (though since it's specific to an English journal, I ended up hard coding the string). What I think is a reasonable solution is to allow styles to reference arbitrary variables, which would then have to be defined in the locale section at the top. If the same fallback behavior is followed as for global locales, I don't see any issues with this.

adamsmith

I can see three potential solutions
1. arbitrary defined terms as per aurimas
2. additional fields (medium or genre) for more item types
3. a significantly expanded list of terms in the locales. Most notably those would need to be item type terms like computer software. That would also help with the MLA style, which currently isn't localizable.

I'm actually tending towards 3, but not strongly yet.

aurimas

Are these terms used widely enough to warrant a global definition? If they are only used in one or two styles, I don't see the benefit. Allowing arbitrary terms would introduce a good amount of flexibility and if ttermsterms are used a lot then there's still nothing to stop us from expanding the list. The best part is, that with arbitrary terms you don't need to wait for CSL updates to use them.

I guess what I'm getting at is 1 and 3 together. (Though 2 might be necessary also in some cases)

fbennett

I like the flexibility that (1) would offer. I'm obviously in favour of (2), given the state of the MLZ database schema. I feel a little cautious about (3), since each new term adds a little burden to i18n maintenance.

adamsmith

So my concern is that 1) - if implemented without 3) - creates a lot of redundant work.
As an additional layer of flexibility I'm happy with it, though, and even for styles with default locale, having terms defined up top rather than hardcoded into affixes and text value seems like a much cleaner solution.


2) - while we can't get around it entirely, it's problematic as different styles use different terminology. E.g. for the case at hand, APA wants [Computer software] but the Cite Them Right book (apparently increasingly popular in the UK) wants [Computer program] http://www.uel.ac.uk/lls/support/harvard6/#computer

So I guess that would mean expand the list of terms, but don't go overboard.

edit: as an additional though - if we want terms for item types we can just use/scrape them from Zotero localization

aurimas

E.g. for the case at hand, APA wants [Computer software] but the Cite Them Right book (apparently increasingly popular in the UK) wants [Computer program]

Sorry if I'm misinterpreting, but (2) would not be a solution to this. This is exactly where (1) would come into play. But I do see the point where if, say, we have 50 styles using the term "Computer program" and 50 using "Computer software", (1) becomes too scattered to localize (though there is an elegant solution using (1) and (3) together). However, this would only be a concern for styles that actually need to be translated to multiple languages, which are not that many.

adamsmith

but (2) would not be a solution to this.

Yes, that's what I meant by saying "it's problematic as different styles use different terminology". Not well expressed, but the point of this example was exactly that 2) won't do here.

fbennett

Content categories are a fuzzy case. "Computer software" can be conditioned on the item type, but something like "Festschrift" would need to be carried in a field, or conditioned on other content. Kind of a horses-for-courses thing.

(Re [3] I meant only to flag a case-by-case caution, not a general resistance to adding terms.)

Rintze

Does (1) imply that we'd remove all hard-coded terms from the schema?

adamsmith

not sure what you mean by removing them from the schema?
If the question is whether best practice should be to have no terms in text value or affixes, my answer would be yes. If the question is whether we want to forbid that via schema my answer is no.

Rintze

Once we allow arbitrary terms to be defined, there is no longer a particular reason to define the existing terms in the schema, no?

adamsmith

I'd think we still need them - terms named in the schema are defined in locales can be used without defining them in each style.

Rintze

So we would prohibit the use of arbitrary terms in the locale files?

And I presume that these arbitrary terms would be "dumb", and wouldn't support features like gender assignability? We current limit gender assignability to terms that can be used with ordinals: the month terms and the number variables (see https://github.com/citation-style-language/schema/blob/master/csl-terms.rnc ). And it also wouldn't be possible to define additional locator terms, since that would require changes to the input data model as well?

aurimas

I think most use cases would only require "dumb" terms, but I don't see why these terms would have to be restricted to "dumb" definitions. I think singular/plural term variants may be quite useful.

Rintze

Singular/plural would fall under "dumb", since that's a shared feature of all terms.

adamsmith

I think we can do without gender, yes.

So we would prohibit the use of arbitrary terms in the locale files?

Yes, I would like to keep a list of pre-defined terms that we have in the locales in every language and that can be used without defining them in the style. The locale files should include all of those and only those.

Rintze

The locale files should include all of those and only those.

Note that CSL 1.0.1 only requires that locale files must contain one or more terms. Unless we specifically require all predefined terms to appear in the locale files (but then, in what forms?), having a core set of terms in the schema helps more with excluding than with including terms in the locale files when it comes to validation.

adamsmith

Right, what I meant to say was the should ideally contain all of those and must contain only those.

I wonder, though. Could it make sense to require all terms? Right now untranslated terms are relatively hard to spot, no? And since they fall back to English anyway, we may as well leave them in the locales in English until they are translated. Or maybe I'm missing something, I don't quite understand the "in what forms" question.

Rintze

Many terms in the locale files are defined in more than one form ("long", "short", etc.). Making sure each locale file has the same terms defined in the same forms would make the schema rather complicated. Not sure we want to be that strict, though, since there are a few languages that currently already have additional forms defined.

Rintze

arbitrary v̶a̶r̶i̶a̶b̶l̶e̶s̶ [terms], which would then have to be defined in the locale section at the top

Mulling this over a bit more, I don't think we can actually use RELAX NG validation to check whether custom term names, used on cs:text, are also defined within cs:locale. Schematron would allow for it, but validators like Jing ignore embedded Schematron rules in RELAX NG schemas.

Not a deal-breaker, but it complicates things a bit.

aurimas

Isn't this already the case with macro definitions?

Rintze

Yes. That's not pretty either :).