[go: up one dir, main page]
Page MenuHomePhabricator
Create Task
Maniphest T380264

Best practices for syncing `twn` branch with our default branch
Open, MediumPublic2 Estimated Story Points
Actions

Description

I discovered that an overeager search and replace prior to using translatewiki resulted in a change of "JOSM" to "JOHM" in all our locale files. I changed them back in our repo but translation PRs continue trying to put the incorrect string back in addition to valid updates. This can be seen throughout https://github.com/OpenHistoricalMap/overpass-turbo/pull/25/files

I would expect twn to be aware of changes to our default branch so obviously my mental model is wrong. Am I supposed to delete twn after accepting a PR? Merge the default branch into it and force commit? This is probably a FAQ but translatewiki.net and this Phabricator site are kind of black boxes to me.

Event Timeline

EricTheise created this task.Tue, Nov 19, 12:38 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptTue, Nov 19, 12:38 PM
Reedy added a project: translatewiki.net.Tue, Nov 19, 2:51 PM
Nikerabbit triaged this task as Medium priority.Tue, Nov 19, 4:54 PM
Nikerabbit added projects: LPL Essential (LPL Essential 2024 Nov-Dec), Unplanned-Sprint-Work.
Nikerabbit set the point value for this task to 2.
Nikerabbit moved this task from Backlog to Ready for dev on the LPL Essential (LPL Essential 2024 Nov-Dec) board.

Your expectations are correct. We perform 2-way synchronization, but for some reason that needs investigation these changes did not get synced to translatewiki.net.

Nikerabbit moved this task from Backlog to System admin stuff on the translatewiki.net board.Thu, Nov 21, 8:59 AM
abi_ moved this task from Ready for dev to In Progress on the LPL Essential (LPL Essential 2024 Nov-Dec) board.EditedThu, Nov 21, 12:46 PM
abi_ subscribed.

When a source string (en.json) is changed in the project, they have to be manually processed by administrators on translatewiki before they are imported into the system for translators to see.

I have a strong suspicion that this happened due to bad import processing from my side. I made the wrong assumption that since it is OpenHistoricalMap, the abbreviation should say OHM and not OSM. Since the translators saw JOHM, they translated it accordingly. Apologies for the mess.

Can you update the source string (en.json) once more, and we'll ensure that the changes are processed properly? We'll take care of updating the translations to use JOSM on our end. After that this shouldn't happen.

abi_ claimed this task.Thu, Nov 21, 1:37 PM
abi_ moved this task from In Progress to Needs Review on the LPL Essential (LPL Essential 2024 Nov-Dec) board.
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits