Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Dutch documents with doclicense #28

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

pkok
Copy link

@pkok pkok commented May 16, 2018

Thank you for your work!

The terms are retrieved from the Dutch Creative Commons license
picker
.

The terms are retrieved from the Dutch [Creative Commons license
picker](https://creativecommons.org/choose/?lang=nl#).
@ypid ypid mentioned this pull request May 20, 2018
Copy link

@TheY3TI TheY3TI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These look good! I would've done the same thing (#29) ;) But what should happen with the Belgian 3.0 licenses as these are for the ones from the Netherlands?

@pkok
Copy link
Author

pkok commented May 21, 2018

Woops!

I'm not really sure how that normally is handled. I'm not aware that Babel has any keywords for Flanders? How is this situation handled for French packages used in Wallonia?

Maybe we should implement a region argument for this package? I can imagine writing English documents in the Netherlands using CC. It feels like it should fall under the Dutch version of that law. Then again, I'm not a law expert...

@ypid
Copy link
Owner

ypid commented May 21, 2018

Maybe we should implement a region argument for this package?

Yes, I think that is what we should/need to do now. I should have seen that coming from the beginning …

But that is nothing we need to reinvent. I would propose we follow the locale system used on GNU/Linux. man 3 setlocale mentions:

A locale name is typically of the form language[_territory][.codeset][@modifier], where language is an ISO 639 language code, territory is an ISO 3166 country code, and codeset is a character set or encoding identifier like ISO-8859-1 or UTF-8.

The good part is that everything except language is optional so that nicely aligns with the use of the lang parameter of doclicense. The only thing which should then be done additionally is to deprecate the lang parameter and prefer a new locale parameter to be precise.

Can you give that a try?

Edit: I checked how babel handles this:

The basic behaviour of some languages can be modified when loading
babel by means of modifiers. They are set after the language name, and are
prefixed with a dot (only when the language is set as package option neither
global options nor the main key accept them). An example is (spaces are not
significant and they can be added or removed): 1

\usepackage[latin.medieval, spanish.notilde.lcroman, danish]{babel}

So not really suitable and they use a different format than the locale one. So with this, I think it is justified to introduce the locale format to doclicense.

@TheY3TI
Copy link

TheY3TI commented May 21, 2018

@pkok great idea, that way we can seperate language from jurisdiction! But

  • how are we going to manage all the translated country names (it only gives us country codes)? Is there a standardised way to convert these to full country names?
  • what about people who are not using Linux, or are we just using their conventions?

@pkok
Copy link
Author

pkok commented May 21, 2018

Also, the number of people using services like Overleaf/ShareLaTeX makes it less practical to use the compiler's locale variables. It also depends on proper settings. For instance, my Ubuntu 16.04 machine, which is in the Netherlands, uses an English interface. Output for locale gives the following:

LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=nl_NL.UTF-8
LC_TIME=nl_NL.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=nl_NL.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=nl_NL.UTF-8
LC_NAME=nl_NL.UTF-8
LC_ADDRESS=nl_NL.UTF-8
LC_TELEPHONE=nl_NL.UTF-8
LC_MEASUREMENT=nl_NL.UTF-8
LC_IDENTIFICATION=nl_NL.UTF-8
LC_ALL=

What should the conclusion be? Is this machine in the US or in the Netherlands?

It starts to sounds like a easy-but-tedious to implement package that handles "locales" (or, as Wikipedia defines it: "countries, dependent territories, and special areas of geographical interest"):

  1. Make an ldf file per language for the names of all locales recognized by ISO 3166, including their adjectival forms and perhaps (singular/plural of) demonyms.
  2. Make a lookup table that matches babel language/dialect/variant keywords with countries
  3. On package load time: If babel is used, read the language/dialect/variant keyword and look up the matching country.
  4. On package load time: If an optional argument is provided, use that ISO 3166 country code as locale.
  5. Later in the preamble: if a command is used (for example, \setlocale{...}), use that ISO 3166 country code as the locale.
  6. Later in the document, you should be able to use several commands to output the locale (for example, \locale) and its variants.

Am I missing subtleties?

@TheY3TI
Copy link

TheY3TI commented May 21, 2018

@pkok If I understand this correctly, step 2 is only to provide a default value for the country to ensure backwards compatibility?
Also, I'd be suprised if someone hasn't already done all of this lookup-table work. Maybe we can look into using an external package?

But, it sounds like a plan @pkok

@ypid
Copy link
Owner

ypid commented May 21, 2018

Sounds good to me. Having native support/another package in LaTeX implementing support for locales would be ideal, but I am not aware of it. The closest we get is from polyglossia which has a variant parameter which we should use as fallback (in case babel is not used). But nevertheless, I think a single parameter doclicense called locale would be suitable.

Also, I'd be surprised if someone hasn't already done all of this lookup-table work. Maybe we can look into using an external package?

If there is a package, please let me know.

Make an ldf file per language should work for that for now.

I am not suggesting to read the locale from the OS. Doing that reliable would require shell escape which I don’t want to require from users.

Supporting changing of locales in the document is another topic which I don’t think is that important for doclicense. So \locale and \setlocale{...} are out of scope I would say.

@TheY3TI
Copy link

TheY3TI commented May 21, 2018

Supporting changing of locales in the document is another topic which I don’t think is that important for doclicense. So \locale and \setlocale{...} is out of scope I would say.

Do keep in mind that babel allows the user to type sections of the document in other languages

Now that I think of it: CC probably doesn't have a version for every locale...

@ypid
Copy link
Owner

ypid commented May 21, 2018

Or we drop the locale idea and just introduce a parameter territory which is a optional ISO 3166 country code. We already have the mapping from babel/polyglossia language to ISO 639 language code in the LDF files btw. That should be used to limit the matrix. So babel/polyglossia language is mapped to ISO 639 language code using LDF files, then we lookup doclicense-${iso_639}.ldf. Figuring out good defaults can be done in doclicense-${iso_639}.ldf. If territory is specified, doclicense-${iso_639}.ldf is loaded and after that doclicense-${iso_639}_${iso_3166}.ldf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants