Dutch is now incorporated. Availiable in test: Advanced Scheduler | 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.
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.
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
