Weekdays and Months are undefined

[papioara]

Today I have downloaded the latest temps-lite version and tested it on my Linux machine. I have seen that in the lang folders' json files with the translations there are definitions for months and weekdays - short and long.

When I launch temps-lite, it seems that the definitions are not recognized, because the window is full of "undefined" where one would expect the month and weekday names. Only the date is recognized.

Is there something wrong in lang.tis, maybe?

[papioara]

[papioara]

Another question: in the json files with the localizations I found that all the weekdays long and short are in a chaotic order. Is there any particular reason for that? At least it makes reading the list more difficult. And are the dots behind the short names in Dutch necessary? If no: shouldn't they be removed for consistency reasons?

[papioara]

Out of curiosity I have compared the lang.tis versions of the actual temps-lite and an older one, where there were no translated month and weekday names in yet. I have created a new "bastard" lang.tis with more definitions put in manually. This has the effect, that no "undefined" messages pop any more, but that in English, German, Dutch, Italian and French with the exception of Spanish the location is displayed in the correct language. The weekdays are always in German, and so are the month names. In the GUI where you can select the languages, everything remains in English now regardless of the chosen language.

All this seems to indicate to me that in lang.tis some of the aforementioned items seem to need their own definitions, too, but I do not know how to implement this. I attach my bastard here for your information - I guess you can draw conclusions from it more easily than I. lang.tis.zip

[papioara]

When I launch scapp in Terminal, there are interesting errors. They may help to give a clue, so I paste them in here:

(Temps-lite-master) BBB 02:18:26 $ scapp warning:css: in @font-face statement, failed to install font at (file:///home/falter/Schreibtisch/Temps-lite-master/rubik.css(4)) warning:css: in @font-face statement, failed to install font at (file:///home/falter/Schreibtisch/Temps-lite-master/rubik.css(9)) warning:css: in @font-face statement, failed to install font at (file:///home/falter/Schreibtisch/Temps-lite-master/rubik.css(14)) error:script: Error: bad syntax : Expecting a primary expression error:script: line: if (($(#current-location).@["city, country"] == "city, country") || ($(#current-location).@["city, country"] == "ciudad, país") || ($(#current-location).@["city, country"] == "Stadt, Land") || ($(#current-location).@["city, country"] == "ville, pays") || ($(#current-location).@["city, country"] == "stad, land") || ($(#current-location).@["city, country"] == "città, paese") || ) { error:script: here:_____^ error:script: file:(file:///home/falter/Schreibtisch/Temps-lite-master/lang/lang.tis(22)) error:script: error:script: error:script: WARNING:Task ended with unhandled error: error:script: at refresh (file:///home/falter/Schreibtisch/Temps-lite-master/api-high-level.tis(200)) error:script: error:script: Error: Wrong type - void, expected instance of function error:script: at refresh (file:///home/falter/Schreibtisch/Temps-lite-master/api-high-level.tis(200)) error:script: error:script:

(scapp:102438): GLib-CRITICAL **: 14:20:05.249: Source ID 867 was not found when attempting to remove it

(scapp:102438): GLib-CRITICAL **: 14:20:06.185: Source ID 998 was not found when attempting to remove it error:script: WARNING:Task ended with unhandled error: error:script: at refresh (file:///home/falter/Schreibtisch/Temps-lite-master/api-high-level.tis(200)) error:script: error:script: Error: Wrong type - void, expected instance of function error:script: at refresh (file:///home/falter/Schreibtisch/Temps-lite-master/api-high-level.tis(200)) error:script: error:script: error:script: WARNING:Task ended with unhandled error: error:script: at refresh (file:///home/falter/Schreibtisch/Temps-lite-master/api-high-level.tis(200)) error:script: error:script: Error: Wrong type - void, expected instance of function error:script: at refresh (file:///home/falter/Schreibtisch/Temps-lite-master/api-high-level.tis(200)) error:script: error:script:

[GirkovArpa]

error:script: line: if (($(#current-location).@["city, country"] == "city, country") || ($(#current-location).@["city, country"] == "ciudad, país") || ($(#current-location).@["city, country"] == "Stadt, Land") || ($(#current-location).@["city, country"] == "ville, pays") || ($(#current-location).@["city, country"] == "stad, land") || ($(#current-location).@["city, country"] == "città, paese") || ) {

Hey, could you try downloading the entire repo fresh and trying it out? Because this code is not in the current version, and it (or other changes) might be the source of the problem.

[papioara]

Just did git clone https://github.com/GirkovArpa/temps-lite.git and launched the app. There (already mentioned above) the weekdays and months appear as undefined in the calendar and in the forecast. The names of the cities are recognized correctly: I picked Aix-la-Chapelle, because it has many different names in European languages and is easier to recognize than Bruxelles.

The errors and the lang.tis I have attached to a previous comment in this thread here are home-cooked this morning, and I know that this is too imperfect to send a pull request, but it produced some interesting results, and I had hoped that the errors might give some clue to what might still be missing.

When I launch the fresh git clone in Terminal, I do not get any other messages beyond the usual complaints about the Rubik font. But despite that you get "undefined" for month and weekday in the calendar and the weekdays in the forecast.

I am sorry I might have confused you, but I hope I made things clearer for you now.

[GirkovArpa]

Another question: in the json files with the localizations I found that all the weekdays long and short are in a chaotic order. Is there any particular reason for that? At least it makes reading the list more difficult. And are the dots behind the short names in Dutch necessary? If no: shouldn't they be removed for consistency reasons?

I used this to generate the translations. Unfortunately JavaScript does not always preserve the ordering of Object keys, and it appears they got jumbled in this case because of that.

I agree that it would look more consistent without the . at the end of some abbreviations, but I haven't got around to fixing that yet 😋

[GirkovArpa]

I've added some test data.

I believe if you re-download the repo and change line 186 in api-high-level.tis from const testing = false; to const testing = true;, one of 2 things will happen:

1. It will load correctly without lots of undefined in the display, indicating that there is a race condition involving harddrive read speed and internet download speed that I have not accounted for.

2. There will still be lots of undefined and we will have made zero progress ☹️

[papioara]

I did so and changed line 186 in api-high-level.tis, but to no avail unfortunately - see below:

In the second screenshot you can see true and false together - true is the left one.

[papioara]

And no new errors in Terminal with const testing = true

[GirkovArpa]

Using a Linux VM at https://www.onworks.net/ I've been able to replicate the issue, so now it's just a matter of time I believe before I figure out what's causing it.

[GirkovArpa]

The issue seems to be here:

function getNextWeekdayName(date, distance) {
  date.day += distance;
  const day = date.toString("%a").toLowerCase();
  return day;
}

date.toString("%a") returns the weekday in your operating system's locale. But the translation code only translates from English to other languages. I need to find a way to fix this.

[GirkovArpa]

Should be fixed with the latest commit.

[papioara]

I have tested it on my machine, and it seems to work there indeed. I am not sure, though, if the city names are always translated a hundred per cent correctly. I tried a couple of which I know they have different names in the languages we have here so far, but this is probably coming from OpenWeather, I guess. It seems that the Linux version of temps-lite is almost perfect now...

[GirkovArpa]

True, OpenWeather is doing the translating. I wonder if perhaps it is mixing up different cities with the same name? There are 2 cities name Springfield in the USA, for example, and only for the USA does it allow specifying state names to disambiguate.

[papioara]

You make an interesting point: Everywhere in the world probably there are cities/towns(villages with the same names, and sometimes it is not as easy as in the US, if they are in different states. In Germany for instance, we, too, have federal states, and you can try and identifiy them by adding it to the name of the town, but this is not reliable. I can give you two examples: we have two major cities named Frankfurt. Frankfurt/Main everybody knows because of the important international airport, but there is also a Frankfurt/Oder on the Polish border. Second: there are at least two towns with the name Halle. One is located in East Germany and a major town located on the river Saale. The other one is a 25.000 or so people small town in the North West. And there also is one with the same name in Belgium, to complete the list, but that one is easy to distinguish. If you enter halle, de in temps-lite, you always get the weather in Halle/Saale and never the weather in Halle/Westphalia. I played around a bit and entered the geocoords from OpenWeather. Temps-lite seems to accept them in the form: &lat=51.5&lon=12 (that's the Halle/Saale ones). You can get them from Openweather if you get more than one search result for the name of a location. You can copy the link with the coords, paste them into temps-lite and prune the beginning of the URL until before &lat, and it seems to work well. Tried it on several towns with identical names. Maybe this would be helpful to know for users who happen to live in such places and should maybe mentioned in the description of temps-lite. What would you think?

[GirkovArpa]

Sounds like a good idea! From reading the openweather docs I was under the impression state prefixes were only supported for the USA. The original temps actually supported coordinates search so it definitely makes sense to add it here as well. I will look into implementating automatic parsing of coords.

Feel free to update README.md with instructions regarding manual inputting of coordinates in the meantime.

[papioara]

Yes, will do...