Renaming some DTD files in Thunderbird

[Jorg Knobloch]

Hi all,

Thunderbird is removing XUL overlays since their support will be discontinued by Mozilla core software soon.

In the process we have renamed
mail/chrome/messenger/addressbook/abCardOverlay.dtd
to
mail/chrome/messenger/addressbook/abCard.dtd

and

mail/chrome/messenger/addressbook/abResultsPaneOverlay.dtd
to
mail/chrome/messenger/addressbook/abResultsPane.dtd

Of the locales I checked, only nl has copied the files, it, fr and es-ES have all retranslated. The resulting files are different and also access keys have changed.

We are in the process of removing more overlays and had planned to rename more files from xyzOverlay.dtd to xyz.dtd.

However, having discovered that this has led to retranslations, we are reconsidering this plan.

Comments welcome.

Jörg from the Thunderbird team.

[Besnik Bleta]

One would think that just mass renaming and uploading from your side
would resolve the issue here. Any reason for not doing so?

If that’s not the solution, informing us for any similar change would
solve it.

Regards,
Besnik

[Ricardo Palomares Martí­nez]

El 25/03/18 a las 10:39, Besnik Bleta escribió:

+1

If you (Jörg) can't / prefer not to touch locale repositories, just
sending your message some days before would likely have worked, too. :-)

--
Proyecto NAVE (Mozilla es-ES Localization Team)
Mozilla Hispano Community

[Axel Hecht]

Hi Jörg,

the answer here comes in a couple of facets:

For one, now that we have cross-channel, a file rename isn't actually a
rename, but a copy. You use a new file for 61, but continue to use the
old file for 60 and older. Once 60 goes EOL, the old file will be removed.
During that time, fixes that localizers want to land across channels
need to land in each copy.

Now to the tooling side: Pontoon doesn't have copy or move detection in
its vcs sync algorithms. That means, if we want to follow the copy in
the localizations, we need to handle this like we handle other migrations:
- we take the regular updates to gecko-strings-quarantine
- we create a scheduled time to sync
- in that sync
-- switch of sync on pontoon
-- migrate and push all localizations
-- push quarantine to gecko-strings
-- switch pontoon sync back on
-- some validation that sync got the right strings back into pontoon

As you can see, that's quite a bit of work. For Firefox, that work's
mostly on flod and matjaz.

Axel


Am 25.03.18 um 03:08 schrieb Jorg Knobloch:

[Jorg Knobloch]

On Sunday, March 25, 2018 at 11:24:33 AM UTC+2, Ricardo Palomares Martí­nez wrote:
> If you (Jörg) can't / prefer not to touch locale repositories, just
> sending your message some days before would likely have worked, too. :-)

My apologies.

We landed the address book changes without being aware of the issue. I only "accidentally" became aware when Mozilla core moved a lot of files for DevTools (from devtools/shim to devtools/startup) about 10 days later.

For now we're landing overlay removals without renaming more DTD files and we're thinking about bundling those changes and following a process that will minimise l10n impact.

Jörg.

[Philipp Kewisch]

Hi Folks,

I was wondering if there are any specific steps needed for Thunderbird.
From Axel's email it seems so, we would need to take care of these steps.

Jörg, can you follow up with Axel to get this done? If it is too much
work you may be better off reverting the rename.

Philipp

[Jorg Knobloch]

On Thursday, April 5, 2018 at 1:20:25 PM UTC+2, Philipp Kewisch wrote:
> I was wondering if there are any specific steps needed for Thunderbird.
> From Axel's email it seems so, we would need to take care of these steps.
>
> Jörg, can you follow up with Axel to get this done? If it is too much
> work you may be better off reverting the rename.

Without knowing much about the mechanics, we renamed two files about four weeks ago and it's too late to rename them back since they have long been re-translated.

If in the fullness of time we revisit this area, we'll follow a better process.

Jörg.