267981 - Move calendar localisation to /l10n

Status: VERIFIED FIXED

(Calendar :: General, defect)

Description

[Mostafa Hosseini]

The calendar localisation files ( currently under
mozilla/calendar/resources/locale ) should be moved to /l10n
The suggested location is calendar/locales/ab-CD/chrome/ ( following the pattern
for browser )

Comment 1

[Simon Paquet [:sipaq]]

And while we're at it we should also enable the build-option to build with other
locales as it's possible with Firefox on aviary.

Comment 2

[Mostafa Hosseini]

Have the locales for firefox and thunderbird moved to the trunk yet?

Comment 3

[Axel Hecht]

no, not yet.

Comment 4

[Mostafa Hosseini]

It seems to be possible to check into /l10n now. To be consistent with the other
directories I think we should be using AB-CD/calendar/chrome/calendar so it
doesn't look like it will be a smooth move from what we have unless shaver can
do some special magic.
Personally I don't mind not having the history of previous checkins if that was
at all possible and if this would at all matter.

Comment 5

[Benjamin Smedberg]

Whatever structure you use in l10n needs to match what you use in the main tree:

mozilla/calendar/locales/en-US/chrome/<files>
matches
l10n/de-DE/calendar/chrome/<files>

And that is the structure I would recommend.

Comment 6

[Mostafa Hosseini]

To be consistent with the rest of the tree I also suggest we move
calendar/resources/locale/en-US/<files> to
calendar/locales/en-ES/chrome/calendar/<files>

Comment 7

[Axel Hecht]

I'm a bit unsure how to deal with sunbird and lightning.

Those are independent toolkit applications, right? From the general scheme, those
should be top level dirs, then, though I'm not confident that I like the bloat.

Should we have some sub-product scheme instead? I'm open for suggestions.

Comment 8

[Mike Shaver (:shaver emeritus)]

Lightning is an extension, not a different app; it's hosted by Thunderbird.  I
think most of the strings will be shared with Sunbird, so leaving it as
/l10n/calendar/lightning for the small set that aren't shared seems appropriate.

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

I see two options here basing on current (http://lxr.mozilla.org/l10n/source/)

1) related products (like lightning, sunbird) are going to have it's own
top-level directory l10n/source/sunbird with locale directories inside

2)  something like l10n/source/ab-CD/sunbird

I think that option two is a lot better because probably those products (like
sunbird) will use a lot of toolkit/dom locales.

Comment 10

[Robert Kaiser]

IMO, the localized files should probably live in
l10n/ab-CD/calendar/

and then an extension like lightning can live in
l10n/ab-CD/calendar/lightning/

The Sunbird-specific files could live in calendar/ and only be pulled by the
jar.mn of calendar or as well like an extension under calendar/sunbird or
something like that...

Not sure about what to do with en-US files in normal mozilla/ cvs partition...
gandalf and bsmedberg are the guys who know that stuff much better (in terms of
how to best deal with automatic builds and such stuff)

Comment 11

[Benjamin Smedberg]

mozilla/calendar/locales/en-US/...
l10n/de-DE/calendar/...

The directory structure of "..." is up to Mostafa/Shaver/whoever else owns
calendar. It can contain the calendar extension + sunbird + lightning,
intermingled or separated.

Comment 12

[Wolfgang Rosenauer [:wolfiR]]

I'm working on it

Comment 13

[Wolfgang Rosenauer [:wolfiR]]

I have a patch ready which works for Sunbird.
The extension and lightning isn't tested yet.
It's possible now to do localized builds for Sunbird.

Comment 14

[Robert Kaiser]

(In reply to comment #13)
> I have a patch ready which works for Sunbird.

Will you also move the existing localizations to the L10n CVS, is that planned at all, should others like us (Mozilla L10n Project) do that?

Comment 15

[Wolfgang Rosenauer [:wolfiR]]

Someone has to move/copy the current localizations to the l10n repository. I don't think that I have write permissions to it. In bug #315059 is an archive for DE attached which already has the correct structure. Anyone has to checkin this and copy the others accordingly to the l10n cvs.

Comment 16

[Robert Kaiser]

(In reply to comment #15)
> Someone has to move/copy the current localizations to the l10n repository. I
> don't think that I have write permissions to it. In bug #315059 is an archive
> for DE attached which already has the correct structure. Anyone has to checkin
> this and copy the others accordingly to the l10n cvs.

OK, I guess I should take a look at those and try to get my current state of de into the right shape (I have current trunk L10n for de-AT in my SeaMonkey L10n packs, I just need to apply the correct structure and name it "de").
We should try to get all other existing calendar locales over there as well though...

Comment 17

[Pavel Franc - Mozilla.cz]

> don't think that I have write permissions to it. In bug #315059 is an archive
> for DE attached which already has the correct structure. Anyone has to checkin
> this and copy the others accordingly to the l10n cvs.

Great. I'll do cs ASA de is in place as a reference locale and I hope that the other locale owners will do their job as well.
 

Comment 18

[Axel Hecht [:Pike]]

(In reply to comment #15)
> Someone has to move/copy the current localizations to the l10n repository. 

If you can create a script that does the copying in a rather automated fashion,
I could help.

Note that the "extension and lighting not solved" is a blocker to this.
Solving that topic is the hard and crucial part of calendar l10n and I want to
see the resolution there before opening up a tld in l10n.

Comment 19

[Wolfgang Rosenauer [:wolfiR]]

Attachment: initial patch

This patch creates new files in calendar/locales/en-US which are almost only copied from calendar/resources/locale/en-US. So for a final checkin those should be moved from an admin. Only calendar.dtd has been changed and removed the workaround at the end of the file (it works w/o this within the new structure).
brand.dtd.in and brand.properties have been moved and brand.dtd is changed.
As all those changes can almost be not separated and the patch is hard to read please comment and test it if you are interested.

Comment 20

[Wolfgang Rosenauer [:wolfiR]]

my proposed (and tested with attached patch) structure on the l10n cvs is the following:

l10n
  AB_CD
    calendar
      chrome
        branding
        calendar
        lightning

Comment 21

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 202647 [details] [diff] [review]
initial patch

Your calendar/locales/en-US/chrome/calendar/contents.rdf doesn't seem to be localizable.

-  locale/en-US/lightning/lightning.dtd				(locale/lightning.dtd)
+  locale/en-US/lightning/lightning.dtd			(/calendar/locales/en-US/chrome/lightning/lightning.dtd)

You should probably use % 
here.

Comment 22

[Wolfgang Rosenauer [:wolfiR]]

you are right. That's one of the left issues. I expect to get more of them as I don't consider the patch "ready". Thanks for the notice.

Comment 23

[Simon Paquet [:sipaq]]

(In reply to comment #22)
> you are right. That's one of the left issues. I expect to get more of them as I
> don't consider the patch "ready". Thanks for the notice.

Wolfgang, any progress on the remaining open issues or is your patch ready for review?

Comment 24

[Axel Hecht [:Pike]]

+locales:
+	@$(MAKE) libs AB_CD=en-US
+	@$(MAKE) libs AB_CD=de

looks like testing code, too. In addition to what gandalf said. I'll need to 
take a closer look, still, though.

Comment 25

[Wolfgang Rosenauer [:wolfiR]]

I hope to come back to it soon. First I have to make trunk build again on modern Linux systems ;-)
The locales target is not really a test. It's a workaround to be able to build all available locales with one make target (for legacy reasons as it is up to now).

Comment 26

[Axel Hecht [:Pike]]

That target should use the all-locales file, then.

Comment 27

[Wolfgang Rosenauer [:wolfiR]]

(In reply to comment #26)
> That target should use the all-locales file, then.

That was also my idea but I wasn't able to get it to work at that time.

Comment 28

[Wolfgang Rosenauer [:wolfiR]]

Just as update what's going on.
We did some preparing work already and moved the branding locale stuff to calendar/locales to make it compatible with l10n CVS usage.
Before we move the bigger part we have to wait for the lightning 0.1 release (and maybe sunbird 0.3a2) to produce no blockers for them.
I hope we get this done as soon as those are out.

Comment 29

[Matthew (lilmatt) Willis]

Please take a look at
http://wiki.mozilla.org/Calendar_Talk:Build_System
and tell me what you think

Comment 30

[Matthew (lilmatt) Willis]

(In reply to comment #28)
> We did some preparing work already and moved the branding locale stuff to
> calendar/locales to make it compatible with l10n CVS usage.

While not a tier 1 app, we would like to eventually replace the void left by abandoning the xpfe Calendar extenstion with enabling Sunbird to be installed as an extension into Ff, a toolkit-ified Seamonkey, or a common Xulrunner. 

Therefore, I think we should stop using the top level "branding", so we don't collide with any host applications that use this namespace already (Ff/Tb). 

After discussion with KaiRo and others, I suggest the following under /mozilla/calendar/locales/en-US/chrome/

calendar
calendar/branding
calendar/lightning    
calendar/sunbird      <-- (if/when needed)

This keeps it simple for localizers as they only need to checkout one directory (calendar) rather than three, and prevents us from "polluting" the top level of l10n with projects

The lightning and sunbird directories would be simple enough to #ifdef out in jar.mn.
I don't think we really want to be shipping separate calendar-ab-CD.jar, sunbird-ab-CD.jar and lightning-ab-CD.jar. Simple is better.

Comment 31

[Axel Hecht [:Pike]]

How does #30 differ from #20?
Note that the pollution of branding has nothing to do with source dirs, but is
merely a question of where those files are put inside the jar, i.e., what jar.mn
does.

Comment 32

[Matthew (lilmatt) Willis]

(In reply to comment #31)
> How does #30 differ from #20?
> Note that the pollution of branding has nothing to do with source dirs, but is
> merely a question of where those files are put inside the jar, i.e., what
> jar.mn does.

Perhaps I'm mistaken. Please check my thinking.

If calendar .xul files refer to chrome://branding/locale/brand.dtd, and those are packaged in an .xpi that is loaded into Ff, wouldn't they use _Firefox's_ brand.dtd rather than calendar's?  This is the problem I want to avoid.

As you said, since jar.mn determines what files map to what chrome URL, the files don't necessarily need to map to the urls one-to-one, and the way to avoid the above scenario would be to simply map to another unused chrome URL rather than using chrome://branding/locale/brand.dtd.

Comment 33

[Benjamin Smedberg]

I'm confused. The standalone app (XULRunner-based or not) is the only thing called Sunbird and the only thing needing branding, right? The Firefox- or Thunderbird- extension doesn't need branding at all, does it?

Comment 34

[Matthew (lilmatt) Willis]

(In reply to comment #33)
> The Firefox- or Thunderbird- extension doesn't need branding at all, does it?

It depends on which .xpi we're talking about.

Lightning currently has its own branding, which is kept its own dtd and properties files [1]. Is this how we want it to work moving forward?

The .xpi "Sunbird-running-in-Ff/Sm" may or may not want to use Sunbird's branding. Calling it Sunbird when it's running inside another app may be confusing and a pain to discern in bug reports ("Are you running Sunbird in Firefox, or just Sunbird?"), but I believe the goal was to make such an extension be as close to standalone-Sunbird as humanly possible, so as to not add another huge matrix of platforms to have to test on. Hence the goal of making Sunbird-standalone _really_ be Sunbird-the-extension + Xulrunner under the hood.

bsmedberg: Are you implying that we should simply #ifdef in the branding information for Sunbird-standalone only in jar.mn?

[1]: http://lxr.mozilla.org/seamonkey/source/calendar/lightning/locale/lightning.dtd

Comment 35

[Matthew (lilmatt) Willis]

After discussion with bsmedberg, WolfiR's plan in comment 20 looks correct.

However, when we want to call ourselves "Sunbird" even when running as an extension under Ff/Tb/Sm, we need to NOT use chrome://branding/locale/brand.dtd but instead register the branding under a calendar-specifc chrome URL. I suggest chrome://calendar/locale/branding. I will file another bug for ensuring we are using the Right Branding in the Right Places.

We can use the same physical files and simply register them twice in jar.mn when running in standalone mode.

Comment 36

[Axel Hecht [:Pike]]

Additional comment:
http://developer.mozilla.org/en/docs/Chrome_Registration#application describes
how to register the branding package part only for the Sunbird application, thus
keeping it in the same jar without messing with the host branding files.

Comment 37

[Robert Kaiser]

Yes, actually, the comment #20 version looks good - and comment #30 is basically the same when you drop the additional "calendar" below chrome/, which is what I also would suggest.

Comment 38

[Matthew (lilmatt) Willis]

mvl and mostafah:

To get this party started, I'm planning to request mozilla.org server ops do a copy-with-history of /mozilla/calendar/resources/locale/en-US/* to /mozilla/calendar/locales/en-US/chrome/calendar/

This would be a _copy_ so that we don't bust the build in the meantime.

Are you both agreeable with this course of action?

Comment 39

[Mostafa Hosseini]

(In reply to comment #38)
> Are you both agreeable with this course of action?
> 
If this proves feasible for the sysops, I have no objections.

Comment 40

[Michiel van Leeuwen (email: mvl+moz@)]

the copy is ok with me.

Comment 41

[Matthew (lilmatt) Willis]

Taking this as I'm doing the actual move.

blocking0.3?

Filter bugspam out using maggieIsMyCat

Comment 42

[Matthew (lilmatt) Willis]

Attachment: rev0 - adjustments to use relocated en-US locale. also removes it from resources

Comment 43

[Zibi Braniecki [:zbraniecki][:gandalf]]

It would be much easier to read this patch if you'd not include the files that are moveing and instead attach "move map" with list of file sources and destinations.

Comment 44

[Matthew (lilmatt) Willis]

(In reply to comment #43)
> It would be much easier to read this patch if you'd not include the files that
> are moveing and instead attach "move map" with list of file sources and
> destinations.

There are no moves in the patch. Just deletions.
The files in question were already copied by MozIT within CVS

Comment 45

[Wolfgang Rosenauer [:wolfiR]]

Comment on attachment 224685 [details] [diff] [review]
rev0 - adjustments to use relocated en-US locale. also removes it from resources

>Index: calendar/locales/Makefile.in

Looks good so far.

>Index: calendar/locales/jar.mn
>===================================================================
>RCS file: /cvsroot/mozilla/calendar/locales/jar.mn,v
>retrieving revision 1.1
>diff -u -8 -r1.1 jar.mn
>--- calendar/locales/jar.mn	10 Feb 2006 23:58:11 -0000	1.1
>+++ calendar/locales/jar.mn	7 Jun 2006 13:14:11 -0000
>+calendar-@AB_CD@.jar:
>+% locale calendar @AB_CD@ %locale/@AB_CD@/calendar/
>+*   locale/@AB_CD@/calendar/aboutDialog.dtd       (%chrome/calendar/aboutDialog.dtd)
>+    locale/@AB_CD@/calendar/calendar.dtd          (%chrome/calendar/calendar.dtd)
>+    locale/@AB_CD@/calendar/calendarCreation.dtd  (%chrome/calendar/calendarCreation.dtd)
>+    locale/@AB_CD@/calendar/calendar.properties   (%chrome/calendar/calendar.properties)
>+    locale/@AB_CD@/calendar/categories.properties (%chrome/calendar/categories.properties)
>+    locale/@AB_CD@/calendar/dateFormat.properties (%chrome/calendar/dateFormat.properties)
>+    locale/@AB_CD@/calendar/email.properties      (%chrome/calendar/email.properties)
>+    locale/@AB_CD@/calendar/global.dtd            (%chrome/calendar/global.dtd)
>+    locale/@AB_CD@/calendar/menuOverlay.dtd       (%chrome/calendar/menuOverlay.dtd)
>+    locale/@AB_CD@/calendar/overlay.dtd           (%chrome/calendar/overlay.dtd)
>+*   locale/@AB_CD@/calendar/prefs.dtd             (%chrome/calendar/prefs.dtd)
>+#ifdef MOZ_SUNBIRD
>+    locale/@AB_CD@/calendar/connectionPrefs.dtd   (%chrome/calendar/connectionPrefs.dtd)
>+    locale/@AB_CD@/calendar/prefutilities.properties (%chrome/calendar/prefutilities.properties)
> #endif
> #includesubst @LOCALE_SRCDIR@/extra-jar.mn

I would not use that extra @AB_CD@ layer because it's already in a localized jar file.

In addition to that we will need a calendar/locales/all-locales file.
The next step could be to enable lightning for localization ;-)

Comment 46

[Robert Kaiser]

(In reply to comment #45)
> I would not use that extra @AB_CD@ layer because it's already in a localized
> jar file.

Umm, that "extra @AB_CD@ layer" is what others (toolkit, thunderbird, suite at least) use as well - it might be unneeded but it's a usual thing to do...

Comment 47

[Wolfgang Rosenauer [:wolfiR]]

(In reply to comment #46)
> Umm, that "extra @AB_CD@ layer" is what others (toolkit, thunderbird, suite at
> least) use as well - it might be unneeded but it's a usual thing to do...

Firefox doesn't do it.
So what's the usual thing? I really don't know. One could say that Firefox is the flagship and the reference ;-) I'm fine with both personally. It should be consistent.

Comment 48

[Robert Kaiser]

Firefox seems to be the only case that doesn't do it... and I personally take toolkit as the reference in most cases :)
Maybe they wanted to do away with it, but overrides and mixtures from different directories made it nearly impossible for everything but Firefox, I don't know - I actually wondered first that Firefox doesn't follow the model of everyone else. I personally prefer to stick with a maybe unneeded loger path and have one common convention thougout the whole app than to have slightly shorter paths but different conventions for toolkit and app-specific stuff.

Comment 49

[Robert Kaiser]

Comment on attachment 224685 [details] [diff] [review]
rev0 - adjustments to use relocated en-US locale. also removes it from resources

>Index: calendar/locales/jar.mn
>===================================================================
>+calendar-@AB_CD@.jar:
[...]
>+#ifdef MOZ_SUNBIRD
>+    locale/@AB_CD@/calendar/connectionPrefs.dtd   (%chrome/calendar/connectionPrefs.dtd)
>+    locale/@AB_CD@/calendar/prefutilities.properties (%chrome/calendar/prefutilities.properties)
> #endif

Could you just leave out that #ifdef and pack those two files unconditionally? It makes everyone really use the same calendar-@AB_CD@.jar and non-Sunbird UI just doesn't use those files/strings. The good thing with this is that a localizer using calendar-en-US.jar as the source for his L10n (e.g. with MozillaTranslator) would never miss common files...

Comment 50

[Robert Kaiser]

Comment on attachment 224685 [details] [diff] [review]
rev0 - adjustments to use relocated en-US locale. also removes it from resources

>Index: calendar/lightning/jar.mn
>===================================================================
> calendar-en-US.jar:
[...]
>+  locale/en-US/calendar/selectAddresses.dtd    (/calendar/locales/en-US/chrome/calendar/selectAddresses.dtd)

And probably this file should be added in calendar/locales/jar.mn as well, so that we really ship the same calendar-en-US.jar for all variants (this file is Lightning-only right now, it seems)

Comment 51

[Matthew (lilmatt) Willis]

Attachment: patch addresses kairo's comments regarding jar.mn

Patch to address the (valid) comments of KaiRo

Comment 52

[Joey Minta]

Comment on attachment 224770 [details] [diff] [review]
patch addresses kairo's comments regarding jar.mn

r=jminta even though the extra packaging still seems odd to me.

Comment 53

[Matthew (lilmatt) Willis]

Removing 315059, 327201 from the blocking list as we're no longer blocking the German localizers.

All locales already having existing localizations in /l10n have been committed there.

All patches have been applied to trunk and MOZILLA_1_8_BRANCH.

Remaining items:
- discuss with Pike/#l10n what to do with "orphaned" locales (locales in resources/locale that don't exist in /l10n yet)

- do whatever we need to

- delete the locales from resources/locale after we're sure all is well

Comment 54

[Matthew (lilmatt) Willis]

(In reply to comment #53)
> Remaining items:
> - discuss with Pike/#l10n what to do with "orphaned" locales (locales in
> resources/locale that don't exist in /l10n yet)

These are:
cy-GB   Welsh
lt-LT   Lithuanian
wen-DE  Sorbian(?)

Comment 55

[Simon Paquet [:sipaq]]

(In reply to comment #54)
> These are:
> wen-DE  Sorbian(?)

Yes, that's Sorbian. A Slavic language spoken in some parts of Eastern Germany with some Germanic influences.

Comment 56

[Axel Hecht [:Pike]]

lt-LT should be lt, we just released our first version of firefox there 
officially.
Welsh has a registered localization of firefox, bug 270208, but that seems to 
never got past a 1.0.x localization. I wonder if the locale should be 'cy' now.
Sorbian seems to be really far out, I don't find any signs of a localization
team for toolkit anywhere.

So, Lithuanian is trivial.
The other two locales should probably try to create an alive-and-kicking 
l10n team to provide good localizations of toolkit to have a good purpose in 
CVS.
Until then, they can provide their locale as extension locale pack, I guess,
but that'd only make sense for the calendar extension itself.

Comment 57

[Matthew (lilmatt) Willis]

(In reply to comment #56)
> lt-LT should be lt, we just released our first version of firefox there 
> officially.

Per Pike on irc, lt has been commited, but only on MOZILLA_1_8_BRANCH, as the lt team hasn't moved stuff to trunk. When they do, calendar will come along for the ride.

Since Welsh and Sorbian have no current toolkit translations, and the calendar localizations have seen no updates of significance in > a year, I'm going to suggest we tag the repository so we can find them easily, and then delete them.

This is all of course unless a Welsh and Sorbian l10n team want to come forward and do the necessary toolkit localizations.

Comment 58

[Matthew (lilmatt) Willis]

Repository has been tagged as: CALENDAR_IN_TREE_LOCALES_R_I_P

If we wish to retrieve or revive the Welsh or Sorbian locales, use this tag.

If we need to go back to the locales as they existed before being copied to /l10n, also use this tag.

I have sent a note to m.dev.l10n and m.d.a.calendar announcing our intention to remove Welsh and Sorbian from our tree entirely.

All that remains is to delete. Patch forthcoming.

Comment 59

[Matthew (lilmatt) Willis]

Attachment: final patch - removes makefile reference

Also, remove /mozilla/calendar/resources/locale recursively

Comment 60

[Joey Minta]

Comment on attachment 224899 [details] [diff] [review]
final patch - removes makefile reference

r=jminta, but don't do the actual removal at least until we get green windows builds.  Also, get an sr since you're touching stuff outside calendar/.

Comment 61

[Matthew (lilmatt) Willis]

> Created an attachment (id=224899) [edit]

Patch checked in on MOZILLA_1_8_BRANCH and trunk.

Still waiting on green Windows Sb builds before removing resources/locale

Comment 62

[Matthew (lilmatt) Willis]

I spot-fixed solaria last night, and we have happy green Windows builds this morning that work!

We're also a week since the move.

Deleted /mozilla/calendar/resources/locale recursively on MOZILLA_1_8_BRANCH and trunk.

-> FIXED! 

Thanks to all who helped!

Comment 63

[Simon Paquet [:sipaq]]

Attachment: Calendar XPI bustage fix

Matthew,
you broke the Calendar extension with your changes:

|make[5]: Entering directory
|'/home/moz-work/mozilla/obj-windows/calendar/xpi'
|make[5]: *** No rule to make target
|'/home/moz-work/mozilla/calendar/xpi/../resources/locale/Makefile.in',
|needed by `../resources/locale/Makefile'.  Stop.
|make[5]: Leaving directory
|'/home/moz-work/mozilla/obj-windows/calendar/xpi'
|make[4]: *** [export] Error 2

http://lxr.mozilla.org/mozilla/source/calendar/xpi/Makefile.in#55 looks like the culprit to me.

Comment 64

[Matthew (lilmatt) Willis]

(In reply to comment #63)
> you broke the Calendar extension with your changes:

Wasn't our consensus that we no longer expect devs to test/fix/etc. the XPI?


> Created an attachment (id=225687) [edit]

-		  ../resources ../resources/locale   \
+		  ../resources ../locales            \

Is this really the only thing needed to keep the xpi working? Does it know how to deal with multiple localizations, etc.?

If so, okay.

If not, and if the rest of the fix is substantial and/or scary, I'd rather leave the XPI broken and remove the option to build it from /m/calendar/Makefile.in

If someone wants to step up and keep the XPI working by doing the extra work needed, they can, but I don't want to.

Comment 65

[Matthew (lilmatt) Willis]

Comment on attachment 225687 [details] [diff] [review]
Calendar XPI bustage fix

I've verified that this alone doesn't fix the XPI. More work is required.

Bug 341646 has been filed about the regression. If anyone wants to do all the work to fix the XPI, that's where it should go.