Re: Swedish calendar localization in official release (sv-kalender.el)?

[Arthur Miller]

Stefan Kangas <stefan@marxist.se> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Just a question/suggestion: can we get a localized calendar for swedish
>> language into official release? There is a small file by Daniel Jensen,
>> found at: http://bigwalter.net/daniel/elisp/.
>>
>> I did a small hack to it, just added names for abbreviated day names and
>> header array since it seems to not be properly initialized if
>> sv-kalender is loaded after the calender.el.
>>
>> In a short mail correspondence with Daniel, he says he has signed FSF
>> copyrights, so I guess, legaly it shouldn't be a problem to include that
>> file amongst few other localizations in lisp/calender?
>
> I support this proposal.  If there are no legal issues, for me it's a
> no-brainer that this file (and some similar ones) should be included
> in Emacs itself.  I don't know if others agree, but I have myself been
> wondering why sv-kalender.el is not just part of Emacs.  If you are
> living in Sweden, the calendar is next to useless for many kinds of
> planning if you don't have that library loaded.
>
> The only drawback I see is that sometimes people stop maintaining
> things once they are merged into Emacs.  I'm not sure what could be
> done about that, or if others here even share that concern.  Perhaps
> we could set it up as a GNU ELPA core package?  Or perhaps I'm worried
> for no reason.
>
> In any case, we should specifically ask the current maintainer to
> continue maintaining it inside of Emacs, and make it clear that we
> have no extra resources or volunteers on our end that can really help
> with that.  Our motivation should be made clear: it is simply to
> distribute this useful library to more users.

Agree, but being part of Emacs gives advantage that potentially
more people will use it, and thus more likely that someone will repport
a bug or contribute fix/improvement. I have forgott to cc Daniel in this
mail, so I filed a bug repport/suggest where I have CC him, so we can
ask him.

>> Maybe the
>> name of the file itself should be adjusted, like calender-swedish.el or
>> something?
>
> (I don't know which conventions could be useful here, but note that
> Swedish is also spoken in Finland.)

Yes of course, I meant something like calendar-LANGCODE.el,
so say calendar-sv_SE.el or calendar-sv_FI.el, so Emacs could choose to
load appropriate file based on value in LANG env. 

>> Also a side question about localizations as found on Emacs Wiki:
>>
>> https://www.emacswiki.org/emacs/CalendarLocalization
>>
>> I can't imagine that day and month names and few other bits related to
>> that information can be copyrighted. Would ot be interesting to
>> collect info from that wiki page into some file with localized names
>> and maybe have Emacs auto load localized names when avialable based on
>> value in LANG env (or whatever variable is suitable), and a variable to
>> turn on/off that behaviour?
>
> From my perspective, the most useful part here is the code to
> calculate when the national holidays are, as the rules for that can be
> quite finicky.  (See sv-kalender.el for example.)

Indeed.

I adapted yesterday Daniel's code to croatian language. Partly because I
haven't seen it in the list on Wiki, partly to learn a bit more about
calendar. What I have noticed immidiately about hollidays, even those
that has to be calculated like Easter, are actually very same for
different countries. I mean croats are mostly catholics, and catholic
easter is same date as protestant's since it is calculated by the same
calendar. I guess same follows for say Russian/Serbian/Greek
calendar. So what really has to be translated are just names of those
hollidays. Compare attached adaptation from sv-kalender to the attached
calender-hr.el.

> Including lists of month names and so on in various languages could
> also be useful, but we should make sure to do it in a clean way.

I was thinking bit of it today, and as I see, ther are mostly strings
that needs to be localized, since for the most part calculations are
already included in Emacs.

As I see there are:

1) strings for the day and month names and their abbreviations that
   every language has to set. Those appear in the calendar buffer when
   user runs calendar.

2) date string has to be adapted to the locale.

3) names of religious hollidays, lunar/solar phases etc has to be
   translated. Calculations can be re-used (somehow). For catholic
   hollidays are same dates in most europian countries (? am I correct,
   I am not 100% but I have faith in this :)). Not all are celebrated or
   equally important in every country, but thay all have names.

4) country specific hollidays, usually official hollidays have to be
   calculated. This are usually fixed, and can't be translated since
   they are specific for each country
   
5) some hardcoded strings in calendar.el that appear in minibuffer or
   elsewhere. I haven't seen any of localizations translate those, but
   it would be icing on the cake if we that could be done too :).

It would be nice if we could somehow translate only strings to avoid
duplication of code as we see now in different translations. I am not
sure how to do this. Easy one is to re-declare everything as it is done
now by different localizations. That excludes hardcoded strings as in 5).

I am though thinking of something else, but I am not sure if it would be
possible: a minor mode that translates strings as found in symbols
automatically. Say if I give it a function or a variable name, it would
look up a list in the function value of a symbol and patch all the
strings in that list by replacing list element with its translation? Say
something like:

(translate-var 'holliday-general-hollidays
               '((list-from1 . list-to1)
                 (list-from2 . list-to2)

                         ...

                 (list-fromN . list-toN)))

And similar `translate-fn'. A variation would be to populate some hash-map
with strings list-to1, ... list-toN, and use list-from1, ... ,
list-fromN as keys for lookup. I could then define a minor mode,, say
calendar-localize-hr, and call translate function on bunch of symbols
where I just need to specify those pairs for translations.

I mean that just as a rough sketch of the idea, I understand it would be
complicated in practice, but would this be possible to do in Elisp? I
mean, in interpreated code it should be possible, but I am not sure if
it would work with native compiler? 

Thus a translation would specify name of symbol to translate and list of
pairs to serve as a lookup/translation. It could also be used to undo
translation if mode is unloaded. Would of course work only from/to
the english language but wouldn't require existing code to be changed,
and could be used elsewhere in Emacs for localizations?

> Even just including sv-kalender.el (renamed to something suitable) so
> that a person living in Sweden can just (require 'sv-kalender) and be
> done with it is a useful step forward, I think.

I agree. It would be even nicer it this could be required automatically
by Emacs, say based on a value of some variable in customize. I see a
lot of manual repetition which to me seems a bit unnecessary. Why
should every user have to retype this, when it can be done once only.

> Thanks for looking into this.  I hope we can see some results for Emacs 28.

Thanks for the input and response, I appolgozie for the very long mail.

calendar-hr.el
Description: Text document