Ephemeris, localized getHolidayDescription

Looking at Actions | openHAB, I can’t understand how to specify the location of my downloaded version of holiday_description_sv.properties (swedish). In the syntax help section, custom xml-files are to be specified with full path in the method calls, whereas no information is given on how to treat the localized properties-file. Anyone who can shine some light on this?
(Running openHAB 2.5.11)

Have a look to this posting [WIP] Ephemeris Documentation - #28 by cweitkamp . The thread itself should give a set of hints.

1 Like

@Wolfgang_S Yes, I’ve been through that before, but without success. Had a look once more, but have yet only found a question here [WIP] Ephemeris Documentation - #24 by tnemrap with a reply [WIP] Ephemeris Documentation - #26 by Marian_Kilinski. The reply is consistent with the method syntax in the Ephemeris-documentation which in turn seems to lack information on how to use the properties file in the method call. See an excerpt from the documentation Actions | openHAB

"To enable localization,

copy the file for your language to your OH setup.
again a folder in $OH_CONF folder, such as $OH_CONF/services is proposed.
use function ‘Ephemeris.getHolidayDescription’ to convert the name according to your localization file."

Still confused (and no success with translation of description) on naming of the properties file (_se, _sv or no extension) and method syntax w.r.t. the properties file (like method calls using xml-files).

I did a simple test for the german translation so this should also work for swedish version:

  • put holiday_descriptions_se.properties to the services folder and use SE in your Ephemeris setup
    as far as I understand the country code is required here to match and find the localized file; in my case it works
  • in case of local holidays you can put it everywhere you like and openhab has read access to; prefered to put it to the services folder, too
  • then you can do something like:
logWarn("Rules", isWeekend(new DateTimeType().zonedDateTime.plusDays(-1)).toString())
logWarn("Rules", getHolidayDescription( getBankHolidayName(new DateTimeType().zonedDateTime.plusDays(-0))) )

in your DSL rules. The first one prints out the string true or false if yesterday was a day during weekend.
The second one prints out the translated name of a Bankholiday for today.

Do these examples answer your question or is something else missing ?

im struggling with the same, but im on 3.0.0. language set to English in GUI.
services/country_descriptions_nl.properties
services/holiday_descriptions_nl.properties (contains Kersemis for testing sake)
Locale set to ‘en_NL’.

2020-12-26 21:35:10.593 [WARN ] [org.openhab.core.model.script.Rules ] - false

2020-12-26 21:35:10.611 [WARN ] [org.openhab.core.model.script.Rules ] - Christmas

changing to language to Dutch in GUI.
Locale set to ‘nl_NL’.

2020-12-26 21:37:39.180 [WARN ] [org.openhab.core.model.script.Rules ] - false

2020-12-26 21:37:39.199 [WARN ] [org.openhab.core.model.script.Rules ] - Kerstmis

So its not grabbing it from the local file.

@Wolfgang_S, I’ll try it out per your advice and get back. Thanks for your your support so far!

Pardon my removed posts above. I hit something on the keyboard unintentionally which sent it half finished.

@Wolfgang_S, after some trial and error and while I was already at it, when adding to runtime.cfg, in order to reproduce German translation:

  • org.openhab.ephemeris:country=de # --> PaperUI, Configuration, System: Country=Germany AND Region=populated for Germany
  • org.openhab.ephemeris:country=DE # --> PaperUI, Configuration, System: Country=empty BUT strangely Region=populated for Germany
  • org.eclipse.smarthome.i18n:language=de # --> Translates the holidays to German from the default (without, and strangely also with a custom holiday_descriptions_de.properties file present in the services-directory, which is probably the same issue as @Mickroz mentioned earlier. The same behavior also after a openHAb restart).

@Mickroz, you made me realized I had not entered the actual localization variables in runtime.cfg:

  • org.eclipse.smarthome.i18n:language=sv # Or “de” for testing as mentioned above. And my mistake earlier that it should be “se”, but actually ought to be “sv” according to ISO639.
  • org.eclipse.smarthome.i18n:region=SE # Or “DE” for testing as mentioned above

Conclusion

  • org.openhab.ephemeris:country must be in lowercase letters (as was already mentioned in the documentation of course). Though, upper case letters seems to work half-way and impacts Ephemeris regions but not country, which must be som sort of bug in the system?!
  • Region: It’s quite confusing with the concept Region w.r.t. Ephemeris and Localization, since it has different meanings in those two contexts.
  • I managed to get default German translations OK, but did not succeed with the Swedish.
  • Swedish language code should be “sv”.
  • @Mickroz’s problem with local properties file is reproduced as far as I am concerned (with holiday_descriptions_de.properties).

In the meantime I also did some trials:

  • I was able to setup/define addtional dates in a separate xml file
  • I was ableto get German translations for existing definitions
  • I was not able to setup own language definitions; this seems not to work or is not supported
  • I was not able to understand where the translations are being taken from as this seems not to be included in the jar files itself; it might be taken from an other service
  • this jollyday/holiday_descriptions_sv.properties at master · svendiedrichsen/jollyday · GitHub seems to be the definitions for svenska names of the days nevertheless I am wondering where the translation Stephanstag for SECOND_CHRISTMAS_DAY comes from as this string ( Stephanstag ) seems not to be in the file. May be there are different versions

=> seems to be good to raise an issue at github

Interesting. So we agree on the fact that the custom xml-files works and that the own/custom/local language definitions properties-file does not seem to be supported (although the documentation indicates so). This should be sorted out somehow, I’ll post an issue on GitHub for this (need to setup an account first so I might not do it straight away…).

True, jollyday/holiday_descriptions_sv.properties at master · svendiedrichsen/jollyday · GitHub is indeed the Swedish language file, which is the one I would like to use, either by default or as a local version, which as we concluded does not seem to work. I’ll post an issue on GitHub for this as well.

When I test the german setup I get “2. Weinachtsfeirtag” from “SECOND_CHRISTMAS_DAY” as expected in jollyday/holiday_descriptions_de.properties at master · svendiedrichsen/jollyday · GitHub. However, “STEPHENS” / “Stephanstag” exist as well. In some older version I found in Jollyday –, “SECOND_CHRISTMAS_DAY” / “2. Weinachtsfeirtag” is missing (but “STEPHENS” / “Stephanstag” is there). Have you actually caught the middle output from getBankHolidayName as “SECOND_CHRISTMAS_DAY” and got it translated to “Stephanstag”?

The code that I have in a rule file:

logWarn("Rules", Ephemeris.getHolidayDescription(Ephemeris.getBankHolidayName(new DateTimeType().zonedDateTime.plusDays(-1))))

Using country=SE in ephemeris.cfg I get the output “Stephanstag”.
Using country=DE in ephemeris.cfg I get the output “2. Weihnachtsfeiertag”.
Region is left empty ( region= ).

Hmmm, even more peculiar. I see the confusion.

As from what I found and mentioned above, maybe you only changed the lookup from the XML-file and not the actual language translation. Probably, you got STEPHENS from the inner call (?!):
:
Ephemeris.getBankHolidayName(new DateTimeType().zonedDateTime.plusDays(-1))

Also, SE may be the upper-case variant that should not be used (or maybe that was only to point out “se”).

Added issues to GitHub for

Missing Swedish language support: Ephemeris localization for Sweden not supported as documentation mentions · Issue #2017 · openhab/openhab-core · GitHub

and

Non-working custom/local language translations: Custom Ephemeris language localization (translation of description) not working · Issue #2019 · openhab/openhab-core · GitHub

I have it in runtime.cfg, but for OH3 it’s slightly different

org.openhab.i18n:language=en
org.openhab.i18n:region=NL

I don’t have a ephemeris.cfg.

country=se

logWarn("Rules", Ephemeris.getHolidayDescription(Ephemeris.getBankHolidayName(new DateTimeType().zonedDateTime.plusDays(-2))))
logWarn("Rules", Ephemeris.getBankHolidayName(new DateTimeType().zonedDateTime.plusDays(-2)))

results in

2020-12-28 09:10:50.850 [WARN ] [eclipse.smarthome.model.script.Rules] - Stephanstag
2020-12-28 09:10:50.863 [WARN ] [eclipse.smarthome.model.script.Rules] - BOXING_DAY

country=SE
results in

2020-12-28 09:13:11.021 [WARN ] [eclipse.smarthome.model.script.Rules] - Stephanstag
2020-12-28 09:13:11.041 [WARN ] [eclipse.smarthome.model.script.Rules] - BOXING_DAY

country=de
results in

2020-12-28 09:14:00.048 [WARN ] [eclipse.smarthome.model.script.Rules] - 2. Weihnachtsfeiertag
2020-12-28 09:14:00.108 [WARN ] [eclipse.smarthome.model.script.Rules] - SECOND_CHRISTMAS_DAY

Country upper- or lowercase doesn’t make any difference.
Source of the second row results must be the country depending holiday file.
Source of the first row results must be the language depending properties file.
No local modified file is in use.

Hello,

I’m trying to get the german description in OH3, but openhab doesn’t find the properties file. I placed the file “holiday_descriptions_de.properties” in the folder “config\services” and restared my openhab instance. The result after calling Ephemeris.getHolidayDescription is:

2021-01-10 13:14:48.245 [WARN ] [de.jollyday.util.ClassLoadingUtil   ] - Could not load class with current threads context classloader. Using default. Reason: ClassNotFoundException: de.jollyday.impl.DefaultHolidayManager cannot be found by org.apache.aries.jax.rs.whiteboard_1.0.9
2021-01-10 13:14:48.254 [WARN ] [de.jollyday.util.ClassLoadingUtil   ] - Could not load class with current threads context classloader. Using default. Reason: ClassNotFoundException: de.jollyday.datasource.impl.XmlFileDataSource cannot be found by org.apache.aries.jax.rs.whiteboard_1.0.9
2021-01-10 13:14:48.303 [WARN ] [de.jollyday.util.XMLUtil            ] - Could not create JAXB context using the current threads context classloader. Falling back to ObjectFactory class classloader.
2021-01-10 13:14:48.816 [WARN ] [de.jollyday.util.ClassLoadingUtil   ] - Could not load class with current threads context classloader. Using default. Reason: ClassNotFoundException: de.jollyday.parser.impl.ChristianHolidayParser cannot be found by org.apache.aries.jax.rs.whiteboard_1.0.9
2021-01-10 13:14:48.827 [WARN ] [de.jollyday.util.ClassLoadingUtil   ] - Could not load class with current threads context classloader. Using default. Reason: ClassNotFoundException: de.jollyday.parser.impl.FixedParser cannot be found by org.apache.aries.jax.rs.whiteboard_1.0.9
2021-01-10 13:14:48.856 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'feiertag' failed: Can't find bundle for base name descriptions.holiday_descriptions, locale de_DE

Any ideas?

1 Like

Hi,

I’ve exactly the same error. I’m on OH 3.0.1. No Ideas by anyone?

What is the rule entry that you use when you get the error message ?

logInfo(“Feiertage”, getHolidayDescription(getNextBankHoliday()))

my ephemeris config looks like this:
:org.apache.felix.configadmin.revision:=L"2"
city=“Essen”
country=“de”
dayset-school=(
“MONDAY”,
“TUESDAY”,
“WEDNESDAY”,
“THURSDAY”,
“FRIDAY”,
)
dayset-weekend=(
“SATURDAY”,
“SUNDAY”,
)
region=“nw”
service.pid=“org.openhab.ephemeris”

The output that I get is:

2021-02-21 18:54:40.470 [INFO ] [.openhab.core.model.script.Feiertage] - Karfreitag

openhab version: 3.0.1-2

java --version
openjdk 11.0.10 2021-01-19 LTS
OpenJDK Runtime Environment Zulu11.45+27-CA (build 11.0.10+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.45+27-CA (build 11.0.10+9-LTS, mixed mode)

mmmh. I’ve migrated from 2.5 to 3.0.1-2 a few days before. To be sure I did a sudo apt-get purge openhab* and reinstalled openhab. Now it’s working. Thanks for testing and feedback.