Languages in multilingual jurisdictions

[georgd]

The current setup of jurism-abbreviations allows quite flexibly handling multiple languages. However, it’s possibly a bit too flexible.

The settings

Different situations are met in the wild:

• multilingual jurisdiction with monolingual subjurisdictions: Belgium, Switzerland
• multilingual jurisdiction with multilingual subjurisdictions: Canada, Belgium, Switzerland
• monolingual jurisdiction with multilingual subjurisdictions (possibly with a preferred regional language): Spain, Italy

Citation requirements

• Usually the authority is cited by its official abbreviation in (one of) the official language(s).
• In case of multilingual jurisdiction the citing author might prefer a certain language, e.g. an author from France might prefer citing the Canadian Supreme Court by its French terms.
• In some cases, unofficial language/script versions might be required.

The issues

• Currently, there’s no policy how to designate a language version. In the case of juris-be-desc.json, the unmarked (primary) language is Dutch and the co-official French version is marked as francais. A French citation style now would have to include francais in jurisdiction-preferences. At the same time, juris-ca-desc.json marks French as fr which is inconsistent with Belgium and will require a second entry in jurisdiction-preferences.
• Having an unmarked variant leads to language versions that might not be detected. E.g. if an Austrian author prefers French over Dutch in Belgian, he will use an appropriate option in jurisdiction-preferences. However, he may prefer English over French in Canadian citations and German over French in Swiss (here, German currently is the primary/unmarked language for national courts) citations. The citation style could inlude this list in the jurisdiction-preferences: de en fr, however this would lead to always reading only the French versions in all three cases, as the English and the German versions are not marked accordingly.
• Inofficial variants should not interfere. They should only be called if explicitly needed, like e.g. a style requiring Japanese court names to be translitterated according to English translitteration rules. They should not, however be called merely because en is listed among the preferred languages in the style.

A possible solution

• Add a property in the file to declare the content’s primary language.
• Generate a localised file for the primary language as well.
• Prescribe ISO two-letter languate codes for official languages.
• Prohibit ISO two-letter codes for inofficial variants.

[georgd]

So, the solution for generating a localised file for the primary language is solvable by the language declarations as proposed in #19.

In addition to the cases listed above, it might be useful to declare an unofficial variant to be used in the UI. This is especially useful in the case of official names in non-latin scripts. Especially scholars in international law might need to cite e.g. Chinese decisions which can be found in translation in certain databases, without knowing any Chinese. Identifying the correct court is currently impossible in the UI.

Thus, the different use cases which should be descernible are:

• name variants in official languages – usually to be used in styles and the UI
• unofficial translations/translitterations to be used in certain styles on explicit request
• unofficial translitterations/translations to be used in the UI

[fbennett]

It will be nice to have transliterations or translations of court/jurisdiction strings for many countries in the UI, but while we can capture the necessary data in the LRR files, deployment in the client wil have to wait for some changes. The jurisdiction data is getting pretty bulky already, and most of it is unneeded by most users. Translations/transliterations for China would more than double the size of its data, and it's already a big slice of jurisdiction data overall. I haven't come up with a concrete plan for it yet, but at some point jurisdiction data should be stripped from the client core, and made available over the wire as requested or as required. When that eventually happens, we'll have capacity to add unofficial traslations/transliterations. (In many cases, of course, an author unable to read the original would likely be citing a translation in any case, or relying entirely on secondary works that interpret the original.)

…

On Monday, August 31, 2020, Georg Mayr-Duffner ***@***.***> wrote: So, the solution for generating a localised file for the primary language is solvable by the language declarations as proposed in #19 <#19>. In addition to the cases listed above, it might be useful to declare an unofficial variant to be used in the UI. This is especially useful in the case of official names in non-latin scripts. Especially scholars in international law might need to cite e.g. Chinese decisions which can be found in translation in certain databases, without knowing any Chinese. Identifying the correct court is currently impossible in the UI. Thus, the different use cases which should be descernible are: - name variants in official languages – usually to be used in styles and the UI - unofficial translations/translitterations to be used in certain styles on explicit request - unofficial translitterations/translations to be used in the UI — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAASMSSBUN6GAZXHXP353W3SDLED5ANCNFSM4QKRGD5A> .

[fbennett]

@georgd Thanks for this very thorough summary of requirements and infelicities. I haven't fully gotten my head around the issues, but here are a couple thoughts for the present, as we wait for the work at #19 to settle down.

• The current naming of the variants ("englished", "french") can be aligned with language tags to make it easier to string things together implicitly from existing parameters set in the processor and in CSL.
• In the desc format, I've set languages with an array of declared roles (notionally "abbrevs" and "ui" at present), which might be useful in addressing the formal/informal divide, and possibly other edge cases.

[georgd]

@fbennett Thank you!

(In many cases, of course, an author unable to read the original would likely be citing a translation in any case, or relying entirely on secondary works that interpret the original.)

I’m specifically referring to the international tax law community and the IBFD, which is maintaining a database that, among others, collects case law from all kinds of nations and provides English translations of them in their database. They even provide a list of courts with abbreviations and English court name translations, so I’m planning to add them to the relevant desc-files with an appropriate label (like en-ibfd) if that’s ok.

[fbennett]

We'll need to deal with a scalability issue for this. As things are currently set up in the new desc format and its "compiler" script, adding an English equivalent for a subset of Chinese courts would generate a full alternative court/jurisdiction mapping and abbreviation list for the entire jurisdiction. Data for China is currently ~380k in the client download, and adding English equivalents would roughly double that. More serious than the (minor) additional download burden, the extension would impact the time required for first-install, as the client grinds away at building SQL database tables for the mappings. That's currently taking 3-5 minutes, and pushing that further may test user patience. If multiple jurisdictions are mapped to English, of course, the bloat will be larger.

To cover requirements like this, I would like to find some way to separate jurisdiction "bundles" from the main client distribution. Plugins would be one option, but that raises issues of programming burden, maintenance, data updates, and mutual compatibility that would attach to each plugin released. The cleaner solution would be to provide for over-the-wire extensions and updates in Jurism directly. That will have a one-time programming burden for designing a sync-down protocol, implementing it in client and server, and tying server-side updates to the GitHub repository. UI support of preference menus in the client is currently coded in Firefox XUL, but anything added to preferences right now will need to be reimplemented in React when Zotero makes the jump (the timing of which we don't know).

Although adding the language variants in the client distribution would be difficult at this stage, there is the option of adding them in the desc files, but omitting their language/variant key from the langs segment of the file. That way, they could be maintained together with the native-language tree, and map` and abbreviation files could be generated for them *relatively* simply by ... cloning the LRR installing npm, configuring the jurisupdatescript to write into the user'sjuris-mapsandjuris-abbrevsdirectories, editing thelangs`` array of the source file, and running the script.

Not ideal, but ... what do you think?

[georgd]

Thanks for your great work!

We'll need to deal with a scalability issue for this. As things are currently set up in the new desc format and its "compiler" script, adding an English equivalent for a subset of Chinese courts would generate a full alternative court/jurisdiction mapping and abbreviation list for the entire jurisdiction. Data for China is currently ~380k in the client download, and adding English equivalents would roughly double that. More serious than the (minor) additional download burden, the extension would impact the time required for first-install, as the client grinds away at building SQL database tables for the mappings. That's currently taking 3-5 minutes, and pushing that further may test user patience. If multiple jurisdictions are mapped to English, of course, the bloat will be larger.

TBH, I don't really mind the longer installation time, as it's a one time thing. But of course the user experience wouldn't be great.

To cover requirements like this, I would like to find some way to separate jurisdiction "bundles" from the main client distribution. Plugins would be one option, but that raises issues of programming burden, maintenance, data updates, and mutual compatibility that would attach to each plugin released.

I think, plugins might be ok but I don't like that idea much. In addition to your sorrows, it's not very user friendly. I prefer a solution that doesn't put this in the user's responsibility.

The cleaner solution would be to provide for over-the-wire extensions and updates in Jurism directly. That will have a one-time programming burden for designing a sync-down protocol, implementing it in client and server, and tying server-side updates to the GitHub repository.

That's preferable in my eye — a mechanism for automatically updating jurisdiction data similar to updating style files without the necessity to reinstall the whole application.

UI support of preference menus in the client is currently coded in Firefox XUL, but anything added to preferences right now will need to be reimplemented in React when Zotero makes the jump (the timing of which we don't know).

Having to write the same thing twice within a not so long time should be avoided, if possible. So, if there's an easier workaround for the time being, it could be worth looking at it.

Although adding the language variants in the client distribution would be difficult at this stage, there is the option of adding them in the desc files, but omitting their language/variant key from the langs segment of the file. That way, they could be maintained together with the native-language tree, and map and abbreviation files could be generated for them relatively simply by ... cloning the LRR installing npm, configuring the jurisupdate script to write into the user's juris-maps and juris-abbrevs directories, editing the langs array of the source file, and running the script.

I don't get that, I think. Are you saying, to add the jurisupdate code to Jurism and have it generate the required files on request? Would that work for variants that are required by a certain citation style as well upon request from a citeproc?

[fbennett]

(Sorry for the delayed response here...)
What I had in mind there was that, without an changes to the client, a patient and technically skilled user could update the Jurism runtime files from a local copy of juris-desc/LRR.
(Meanwhile, it seems that over-the-wire style updates are not yet working, so I'll need to polish my skills for protocol debugging before raising the sights to jurisdiction bundle downloads...)