700808 - Move non-shared editor strings to a different directory

Status: RESOLVED WORKSFORME

(MailNews Core :: Build Config, defect)

Description

[Mark Banner (:standard8)]

Attachment: Proposed fix

Currently all the Composer/Composition strings live in editor/ui/locales. In the jar file there is an ifdef MOZ_SUITE, for strings that are Composer only.

However, due to the way 1l0n works, the rule is that ifdefs don't work for l10n. Therefore any locale that localises Thunderbird, has to localise *all* the editor/ui/locales files.

If we move these files to a different directory, then I think there are the following benefits:

- Removes some of the potential confusion (that I have every time I review a patch there) of what a particular file belongs to (composition versus composer).
- Removes just under 300 strings from the ones that localisers have to do for Thunderbird.
- Ensures that Thunderbird doesn't ship a set of files (the redundant localised ones) that it doesn't need to.

I've currently gone for editor/composer, as that seems to keep them in approximately the same place, works with the tools, but does the necessary separation.

I think this patch is probably final, but I'm offering it up for feedback first.

If we land this, I'd propose that I would organise a script to go through the localisers directories and do a hg move of the appropriate files - either one they can run themselves, or one we do automatically when it reaches aurora.

Comment 1

[Robert Kaiser]

I'm not really happy with moving around strings without moving the files that use them as well.

Comment 2

[Mark Banner (:standard8)]

We can move the content files as well if necessary, that shouldn't be too much effort as I think they are already ifdeffed as well.

Comment 3

[Robert Kaiser]

(In reply to Mark Banner (:standard8) from comment #2)
> We can move the content files as well if necessary, that shouldn't be too
> much effort as I think they are already ifdeffed as well.

That would be good and much cleaner (also would make things easier when editing the files as we'd see easily which files affect Thunderbird and which don't).

Comment 4

[Axel Hecht [:Pike]]

Comment on attachment 573007 [details] [diff] [review]
Proposed fix

Review of attachment 573007 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me in theory, I don't really have a opinion on the bug itself.

You probably want to patch all of the l10n.ini files, the plain l10n.ini as well as aurora and beta ones, as the change in directories will be moving through the channels along with the l10n.ini files. I.e., changing l10n-aurora.ini on comm-central doesn't affect things, but it does the right thing once comm-central migrates to comm-aurora all by itself.

I guess we could hg remove the 1.9.2 and miramar ones now, too.

Comment 6

[Ian Neal]

Comment on attachment 573007 [details] [diff] [review]
Proposed fix

As Robert suggested could the relevant xul/js files be moved too.

Comment 7

[[e-mail]]

(In reply to Mark Banner from comment #0)
> However, due to the way 1l0n works, the rule is that ifdefs don't work for l10n.
Presumably this is because it's unclear which files are needed for Thunderbird, rather than any technical reason.

Comment 8

[Mark Banner (:standard8)]

(In reply to [e-mail] from comment #7)
> (In reply to Mark Banner from comment #0)
> > However, due to the way 1l0n works, the rule is that ifdefs don't work for l10n.
> Presumably this is because it's unclear which files are needed for
> Thunderbird, rather than any technical reason.

No its a technical reason. compare-locales works on directory basis, l10n repacks works on a directory basis, localisers work on a directory basis etc etc (I certainly remember seeing a few years ago that localisations don't do ifdefs, and that's still true).

Comment 9

[Axel Hecht [:Pike]]

We're trying to keep our file formats out there as simple as possible, so that the folks that build infrastructure for localizers out there can handle it.

That kinda rules out preprocessing our files, in particular if it's totally unclear what a tool like narro should actually do.

On a more meta level, we're localizing the source. So the localization of a source file would have to not just localize the strings, but the logic as well. That's pretty steep, in particular as there's little to gain in general. Like, worst case you're shipping a few dozens extra strings, right? compared to a dozen MB download, that's not worth it.

Comment 10

[[e-mail]]

(In reply to Axel Hecht from comment #9)
> That kinda rules out preprocessing our files
I already knew that preprocessing dtd/properties files was a no-no, but only because of reasons that don't apply to jar.mn which isn't itself localised. I don't actually know how compare-locales or repacks work so it wasn't clear that they were unable to cope with a preprocessed jar.mn either.

Comment 11

[Axel Hecht [:Pike]]

Taking it more to the meta level, we're localizing the source, and not something as it may or may not be built. So processing, inside a particular file, or selecting particular parts of the tree, just don't happen.

Technically, compare-locales works on a module basis, that is, anything in foo/bar/locales/en-US/** is localized, given that l10n.ini references foo/bar.
jar.mn are going through the preprocessor, so you can only ship those files in part.

The l10n dashboard and the l10n-merge logic won't know about those details of your build, though.

Comment 12

[Mark Banner (:standard8)]

I'm not working on this at the moment, but I'd love to see it improved for localisers.

Comment 13

[Magnus Melin [:mkmelin]]

We moved the entities we needed for Thunderbird out of editor/ years ago. -> WFM