Dutch is now incorporated. Availiable in test: Advanced Scheduler App för Homey | Homey
@Raeven: If it looks good, please let me know, I will push to live.
App was auto-updated to 0.1.22 and for some reason I’m not seeing any Dutch translations.
I even restarted the app, just in case, but it makes no difference.
I’m guessing some config is missing.
But as soon as it works, I will check how the translations work out in the UI and will let you know if it’s good.
@Raeven : Stupid error in my end. New version in test.
I would like some advise. I’m thinking about how to add functionality that helps out in the scenario that the sun events actually are too late or too early to be relevant for what the user wants. So the first thing really boils down to what scenarios needs to be handeled. The alternatives I can think of are:
- Trigger only if [sun event] is before/after [fixed time].
- Trigger first/last of [sun event] and [fixed time].
- Any other scenarios that I have missed…
The questions then becomes:
a. Will the two alternatives 1, 2 cover all scenarios that users need or are there more variants needed?
b. Is there a way to setup the schedules using only one of 1 or 2 but still beeing able to accomplish what is intended in both scenarios (I’m lazy, can we manage with only one of them)?
c. Do we need to have the possibility to use both 1 and 2 in the same schedule event (I’m a bit out of focus, please help me think).
After feedback on this, I will start implementation quite soon I think
Yes, this version definitely works.
I’ve had a good look at it and the Dutch translations certainly are good, but might need a tweak here and there.
However, I’ve got some observations and questions for you @Fredrik_Palsson :
- The “Help” tab’s texts are hardcoded, any plans on doing these with translations as well?
- When a tag is defined a blue label containing the type text is shown, these too aren’t translated.
- When summarizing a schedule event (e.g. “Solar: Dusk, offset: 00:15”) the Dutch translation could be better. When translating “Solar” and “Sun event”, I decided to go with “Zonnenstanden” (plural, basically meaning a collection of Sun Events) and to go with “Zonnestand” (singular, meaning Sun Event). In the translation I was expecting the summary to start with “Zonnestand” since it’s referencing just one specific event. Any plans on changing this translation? If not: I think it’s best if I work around it by simply translating “Solar” into the singular version also.
- When editing a schedule event based on solar, changing nothing and then closing it… does change something: it reverts to time-based (I’m guessing this isn’t a feature… so, a bug?)
The “Help” tab’s texts are hardcoded, any plans on doing these with translations as well?
That is me beeing lazy. I will do that. Shouldn’t be too hard.
When a tag is defined a blue label containing the type text is shown, these too aren’t translated.
Didn’t realize they were translated by the Homey app as they seem so “global” in their meaning. Will fix.
When summarizing a schedule event (e.g. “Solar: Dusk, offset: 00:15”) the Dutch translation could be better. When translating “Solar” and “Sun event”, I decided to go with “Zonnenstanden” (plural, basically meaning a collection of Sun Events) and to go with “Zonnestand” (singular, meaning Sun Event). In the translation I was expecting the summary to start with “Zonnestand” since it’s referencing just one specific event. Any plans on changing this translation? If not: I think it’s best if I work around it by simply translating “Solar” into the singular version also.
It might work to remove "Solar: " from “Solar: Dusk, offset: 00:15”, what do you think? It is redundant info, right? If it says “Dusk” that implies it is a sun/solar event. Also, it might make sense to change the offset part to “Dusk, 00:15 after” or “Dusk, 00:15 before” dependent on sign of offset. What do you think?
When editing a schedule event based on solar, changing nothing and then closing it… does change something: it reverts to time-based (I’m guessing this isn’t a feature… so, a bug?)
It seems that is a bug in the vue or more likely vuetify framework. The radio buttons are not initialized in a correct way. I will look for a workaround. Thanks for bringing this to my attention.
During translating I opted to avoid programming jargon and use the same terms Athom uses for the Homey variables. In short: “bool” will be “Ja/nee” (Yes/no) and “string” will be “Tekst” (Text).
It is indeed implied, as far as that is concerned: less text is more (space left on our mobile device 
).
If you were to summarize an offset like that, I think a more casual user would certainly understand it far better. So yes, I certainly think those are good ideas!
1 Like
Bit tough to wrap my head around (atleast, at the moment).
So, instead of trying to match your train of thought… I’ll share mine instead 
The way I see it, when creating a schedule event you can opt for time-based or solar.
When selecting solar, selecting the sun event, entering an offset and then you should have the option to limit it because it might be too late or too early.
Something like:
Sunrise (offset 00:00) unless “
input for time” is “dropdown with before or after”.
(am I making sense here? 
)
I guess that is scenario 1?.. isn’t that enough to cover all 
Because scenario 2 sounds like exactly the same, just from a different perspective.
I think UI wise “limitting solar” will appeal to most users since it ‘feels’ more natural/logical… you either want time, or solar (with perhaps a limit).
1 Like
Now there is a new version in test, and I guess it will be pushed to live quite soon.
Fixes:
- Translation suggestions implemented (@Raeven and @DirkG, please if you have time check if transaltions are relevant).
- Bug with schedule event not beeing initalized as sun event when editing.
- Improved presentation of sun events and offset in schedule event main view.
Hope it works well for you.
Ow, nice!
I’ll get right on it. 
@Fredrik_Palsson I created a new pull-request!
I still have a few minor findings though (let’s just say I test thoroughly 
).
- The text “Not set” is hardcoded in
WebSettings.ts. - Also, when setting a solar event with a negative offset, save, change to time-based and save again. This results in negative time.
I think you translated select_event properly to Dutch, though I can’t find it in the UI. Where (and when) is it located?
I created a new pull-request!
Great! Thanks! Merged.
I still have a few minor findings though (let’s just say I test thoroughly
Very much appreciated! An application is often only as good as the testers and users make it 
- The text “Not set” is hardcoded in
WebSettings.ts.
Easy fix. Replaced by ’ ’
- Also, when setting a solar event with a negative offset, save, change to time-based and save again. This results in negative time.
That is what you get when you are lazy and reuse a property for two things. This is really bad design, but I beleive I will have to stick with it for now. I plan to redo the settings structure in the next major version and then I will create a “read version 1, save version 2 function”. For now I will make it work as it is. Will give it a few minuts thought.
I think you translated
select_eventproperly to Dutch, though I can’t find it in the UI. Where (and when) is it located?
The vuetify components are playing tricks on me. The idea is that when solar is selected, but no event is choosen in the dropdown, the rule should say “Select event” (and it does, if you open the dropdown and close it without selecting an event). I have a hard time saying why it does not show the rule text when displayed initialy (there is no event selected at that time)…
I beleive there will be a new version tonight. Again thanks for your efforts!
1 Like
@Raeven & @DirkG, new version with your translation suggestions in test now.
@Raeven, bug with offset fixed. Please test if you can spare the time.
Looking forward to your feedback.
1 Like
Looking good, as far as I am concerned!
1 Like
@Fredrik_Palsson For some reason, it doesn’t seem to be running anymore since the update. (or atleast, not triggering)
Restarted it (just like this morning), but this time it works. Weird.
Started to use the app today. Saves me a lot of flows
I have an idea. Is it possible to show the flows which are triggered by a schedule. So if I look at a schedule, i think it’s handy to have an overview of the flows which are triggered.
@Raeven: If it happens again, please let me know and I will look into it, for sure!
Glad you appreciate the app.
Thanks for the suggestion. Do you mean that you want to be able to see (in the app) what flows will be triggered by a certain schedule? If that is the case I do not know if that is technically possible. I’m simply not sure that an app can see what flows are setup by the user until the app triggers. When the app triggers, the system returns all flows that are setup, but before that I don’t know how to get that info. I will look into it, however.
That’s exactly what I meant. Would be a great addition so I hope it’s technically possible.
hello, same over here. This morning ad 5 it didn’t trigger a flow as it supposed to do. Can i help to make troubleshooting easier? I use app version 0.1.26
