Applies different filters in dark mode: invert+rotate for layers without
hillshading, dim for layers with.
Doesn't implement any controls to changing the filter and, consequently,
doesn't store selected values. For storing I'd start with deciding if
#5339 is ok first.
?
--
Part 5 of https://github.com/openstreetmap/openstreetmap-website/pull/5283 that
adds the button to subscribe/unsubscribe from a note.

You can view, comment on, or merge this pull request online at:
https
@gravitystorm
> If we implement my Option 4b proposal, and if we implement some
> straightforward preferences
Your original description of *Option 4b* didn't include implementing
preferences, it had "we shouldn't control those colours in dark mode", that's
completely different now. It even lo
Most of error messages are not translated. `report_error` receives many from
exceptions defined in `lib/osm.rb`, no translations there.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/5314#issuecomment-2489801776
You are receiving
> Maybe for discussion in #5328 to conclude?
@matkoniecz The problem is that the map should not have been dimmed to begin
with, especially without any proper discussion. This should be merged and the
map should remain as default until #5328 is concluded.
--
Reply to this email directly or view
>It's also not helpful to dismiss other opinions with "people don't know how
>things work, so they're scared and afraid of change".
I explained some technical reasons why messing with the maps appearance means
tampering with their message. It's measurable in numbers, don't dismiss it as
uninform
Merged #5314 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/5314#event-15371213528
You are receiving this because you are subscribed to this thread.
Message ID:
___
rails-
Merged, thanks for the updated version.
I'm interested to hear any thoughts on the translations:
> "I'm not sure if the error messages should come from the translation system.
> Other usage of report_error is inconsistent whether error strings are
> translated or not."
We can always refactor t
> Let's suppose we have a group of people who don't want any filter and a group
> of people who want inverse.
Yes unfortunately it's not possible to make everyone happy when their
preferences are in conflict with each other. But we need to pick a default
behaviour for when dark mode is active (
In any case, the current implementation of the dimming filter for all dark mode
users is problematic.
I believe that providing an easy way to switch between light and dark maps
independent of the UI like
[this](https://github.com/openstreetmap/openstreetmap-website/issues/5324#issuecomment-2480
There weren't any *problems* with the code. Not having an error message is not
a *problem*. You could as well have said that not adding `destroy` together
with `create` is a problem because it requires changing a.k.a. fixing routes
and abilities.
--
Reply to this email directly or view it on G
Changed to have error messages right away.
The original version had response bodies intentionally undefined, and they are
still intentionally undefined for ok responses.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/5314#issuec
No, that's not what I meant. A "fixup commit" is a commit that's added to a
pull request that fixes problems with code introduced in the same pull request.
>From CONTRIBUTING.md (emphasis added)
> Avoid including "fixup" commits. If you have added a fixup commit (for
> example to fix a rubocop
Is this not an exact duplicate of #5327?
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/5340#issuecomment-2489114488
You are receiving this because you are subscribed to this thread.
Message ID:
_
> How would you like to have the button indicate that it's disabled then?
I think the tooltip is enough, but yeah I see your point.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/5329#issuecomment-2489102649
You are receiving
It’s unfortunate that a website has to consider implementing this at all.
Ideally it could just respect `prefers-color-scheme` and let the browser handle
asking/remembering your preference.
[ or anything else?
? Now I changed it to always look up the note. Is
there still a fixup?
--
Reply to
> edit on mobile version is a great idea, but it does not really make sense
> without links to mobile editors
Does enabling iD still counts as "not really making sense"?
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/5326#issu
Let's suppose we have a group of people who don't want any filter and a group
of people who want inverse.
> I think the principle should be that the decision on what each map looks like
> in dark mode should be delegated to the cartographers for that map layer.
This proposes to let *the cartogr
Looks good to me. Only two small things:
* PR contains a fixup commit (i.e. a commit that changes code that itself is
added by this PR)
* I'm not sure if the error messages should come from the translation system.
Other usage of `report_error` is inconsistent whether error strings are
translated
We have this in readme
> A fully-functional openstreetmap-website installation depends on other
> services, including map tile servers and geocoding services, that are
> provided by other software.
Maybe we should mention cgimap too.
--
Reply to this email directly or view it on GitHub:
https
> Would #1478 work also when user has no got any relevant app installed yet?
As is no, but you could show a popup or similar if nothing was installed (just
as it now asks you to start JOSM on desktop), potentially you could offer to
directly install an app, but that all gets kind of complicated
Would #1478 work also when user has no got any relevant app installed yet?
Maybe I misunderstood how it works but AFAIK not.
> PS: I'm not naive enough to assume that this will happen in any form,
> naturally everybody will want their own link for marketing purposes.
I would prefer edit menu li
> edit on mobile version is a great idea, but it does not really make sense
> without links to mobile editors
It doesn't really need links, the JOSM RC interface is trivial to implement for
any Android app, it is just an issue with the way the rails-ports generates the
URL.
See https://github.