-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
202412 Upstream merge #261
Conversation
Unused since commit 0c7c950
Text and html templates use .hi instead
Also add Ubuntu 24.04 and drop 20.04 as 24.04 is needed for ruby 3.1 without rvm so we should test it.
Added greeting 'Hi {user display name},' to friendship notification email. As a side effect, user_mailer.friendship_notification.hi is not anymore reported as unused.
Bumps [google-protobuf](https://github.com/protocolbuffers/protobuf) from 3.25.4 to 3.25.5. - [Release notes](https://github.com/protocolbuffers/protobuf/releases) - [Changelog](https://github.com/protocolbuffers/protobuf/blob/main/protobuf_release.bzl) - [Commits](protocolbuffers/protobuf@v3.25.4...v3.25.5) --- updated-dependencies: - dependency-name: google-protobuf dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]>
… to be in settings.local.yml as they should be.
… two pressures. It is easier to track upstream changes to openstreetmap-website when there's less potential for merge conflicts. settings.yml is now identical to upstream and all OHM modifications are made in settings.local.yml; that file is not checked in to source control but a fleshed-out skeleton is available at example.settings.local.yml. What information is in there is publicly available with the exception of OAuth IDs, and those are generated per installation. These two files should be identical to those in images/web/config/ of the ohm-deploy repo and they are manipulated by the start.sh script in the parent directory. Those scripts have been modified so that they use the proper settings file for variable substitution.
This is such a huge update to translations that I cannot process them manually to check for issues. I'm just blanket importing updates to translatewiki.net even if they are incorrect (e.g. some translations being updated From OpenHistoricalMap to OpenStreetMap). |
Big problem with this work : rather that to change original English message; many translated messages have been changed (and badly). One example here:
According to this: https://translatewiki.net/wiki/Support#OpenHistoricalMap_and_Fuzzybot, it seems that the problem comes from your side, not from translatewiki and its bot. Could you fix all these bad translations? |
@Nikerabbit & @Mahabarata: over the next few days I'll revert the translations to what they were before the upstream merge. I apologize for the disruption. |
I promised to open a PR around this work today. There remain issues with this draft status PR.
The timeslider doesn't load. There are CORS issues with
ohm-inspector
and other URLs that shouldn't be in play. Next steps are to track these down:I am concerned about
:oauth2
-related tests that are failing. I have not had time yet to look at oauth2 functionality.I believe most translation strings are in sync; one exception relates to
privacy-policy
where we depart from upstream's format and this should be straightforward to remedy.