Stefan Kangas writes: > Arthur Miller 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.