Closed Bug 792748 Opened 12 years ago Closed 12 years ago

MPL 2 upgrade: l10n for it

Categories

(Mozilla Localizations :: it / Italian, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gerv, Assigned: l10n-it)

References

Details

Attachments

(1 file, 1 obsolete file)

This language needs some or all of its l10n files to be upgraded to the MPL 2 licence. The current status in the aurora repo http://hg.mozilla.org/releases/l10n/mozilla-aurora/ is:

it
Summary of Licenses in Files
============================
 Number  Percent License
------- -------- -----------
    485   49.79% mpl2
    329   33.78% <none found>
    146   14.99% mpl/gpl/lgpl (standard block)
     14    1.44% <unknown license>
----------------------------
    974 files processed

I have a script which can do the relicensing automatically. I will provide a patch here. Once a patch has been provided, please commit it as soon as possible. The aim is to have the relicensing finished by the end of September.

Thanks :-)

Gerv
Attached patch Patch v.1 (obsolete) — Splinter Review
Attachment #662952 - Flags: review?
Assignee: gerv → l10n-it
I have a big problem with this bug :-\

We all use Mozilla Translator to localize, which means that you can land this patch but the next export will revert all changes. And this'll create a big mess when I'll have to merge central and aurora.

Take for example this file
http://hg.mozilla.org/mozilla-central/file/tip/browser/locales/en-US/chrome/browser/devtools/responsiveUI.properties

The license header is missing in the original English file! 

Once you fix the original en-US files, the localized files will be automatically ok, so please fix en-US before messing with local repositories.
flod, gerv can't mess, he doesn't have push access ;-) .

If there are chunks that are not applicable, I suggest that you just drop them, and take the rest as helpful input. From past experience, make sure to not have a <?xml ?> decl after the license comment in the search xml files, that just broke japanese. The patch is correct, just saying.
I checked bug 715549 (In reply to Axel Hecht [:Pike] from comment #3)
> flod, gerv can't mess, he doesn't have push access ;-) .

"Messing with" was the wrong word, I meant more "work on en-US before fixing local repositories".

As I said taking this patch will only create problems for how we localize, both the fact that we use Mozilla Translator and we mostly work on central (Thunderbird is the exception). 

I checked bug 715549 and, for what I understand, the same script/patch is being worked on en-US and central.

The question at this point is if we can ignore this for Aurora in this cycle, work on l10n-central and run again this script against l10n-central instead of Aurora in a few days to check what's still missing.
I glanced at some files, and it seems that we got a mix of relicensing on comm-central and comm-aurora that didn't get picked up by your files, and some new files in en-US that landed after the mozilla-central relicensing.

Feel free to attack this on central only, if that makes more sense, but the en-US code should (regressions aside like devtools files) be properly relicensed on aurora. That's why we waited 'til now until we touch l10n.
@gerv
Is the script that created this summary available somewhere so that I can run it on l10n-central?

Summary of Licenses in Files
============================
 Number  Percent License
------- -------- -----------
    485   49.79% mpl2
    329   33.78% <none found>
    146   14.99% mpl/gpl/lgpl (standard block)
     14    1.44% <unknown license>
----------------------------
    974 files processed
flod: en-US is supposed to have been done in mozilla-central some time ago...

Pike: you were the one who said aurora was the tree to use to create all the patches. Is that actually not the case for some locales?

I can relicense a different tree if you tell me which one to relicense.

Gerv
(In reply to Gervase Markham [:gerv] from comment #7)
> Pike: you were the one who said aurora was the tree to use to create all the
> patches. Is that actually not the case for some locales?

taking this offline.
(In reply to Axel Hecht [:Pike] from comment #5)
> some new files in en-US that landed after the mozilla-central relicensing.

Yes, there's not much I can do about this. I can't keep all the trees in perfect sync. If you check in a patch which adds a license to a file in the "it" tree, and there's no license in the file upstream, and so it subsequently falls off, I think we just have to live with that.

Gerv
@gerv
I took the time to read the whole patch and – if I didn't miss anything on my side (Firefox & Fennec) - these are en-US files that need updated license headers (currently missing)

/browser/locales/en-US/chrome/browser/devtools/responsiveUI.properties
/browser/locales/en-US/pdfviewer/chrome.properties
/browser/locales/en-US/pdfviewer/viewer.properties
/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.dtd
/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties
/toolkit/locales/en-US/chrome/mozapps/help/help-toc.rdf
/toolkit/locales/en-US/chrome/mozapps/help/welcome.xhtml

@iacopo 
Can you check your files? Most of the missing license headers are from suite, calendar and extensions (IRC, venkam). 

There's also a /chat folder but I have no idea what's used for :-\
Pushed changes to l10n-central for those files that are not managed in Mozilla Translator
http://hg.mozilla.org/l10n-central/it/rev/e7f9365cf635

Then fixed broken xml files (smart copy&paste)
http://hg.mozilla.org/l10n-central/it/rev/09728a7be792
I'll have surely a look at them (sorry for being late, I forgot about this). My question is: is SeaMonkey actually switching to MPL2? Should I relicense my files anyway?
:iacchi: The whole of m-c and c-c are switching to MPL 2, including SeaMonkey.

The aurora branch now looks good to me. :-)

Gerv
Tried the attached patch but it doesn't seem to work well
Fails on all /chat files (probably because they've been updated in the meantime) and also on these files

patching file browser/profile/chrome/userChrome-example.css
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file browser/profile/chrome/userChrome-example.css.rej
patching file browser/searchplugins/hoepli.xml
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file browser/searchplugins/hoepli.xml.rej
patching file extensions/venkman/chrome/venkman-output-locale.css
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file extensions/venkman/chrome/venkman-output-locale.css.rej
patching file mobile/xul/updater/updater.ini
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file mobile/xul/updater/updater.ini.rej
patching file suite/profile/chrome/userChrome-example.css
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file suite/profile/chrome/userChrome-example.css.rej
patching file suite/profile/chrome/userContent-example.css
patching file suite/updater/updater.ini
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file suite/updater/updater.ini.rej
patching file toolkit/chrome/mozapps/extensions/extensions.dtd
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file toolkit/chrome/mozapps/extensions/extensions.dtd.rej
patching file toolkit/chrome/mozapps/help/help-toc.rdf
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file toolkit/chrome/mozapps/help/help-toc.rdf.rej
patching file toolkit/chrome/mozapps/help/welcome.xhtml
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file toolkit/chrome/mozapps/help/welcome.xhtml.rej
Completed with errors, see above

I'll try to fix these in the next hours and apply the patch to Aurora, then I won't look forward to merge day...
Actually I don't think anyone is working on /chat. You don't, I don't (Chatzilla is in extensions/irc and not in /chat) and I don't think Roberto is working there, too. Maybe it's an old folder no more used? But looking at the file they're being modified, and looking at their names maybe we're actually all working on them. I don't know.
(In reply to Iacopo Benesperi [:iacchi] from comment #15)
> Actually I don't think anyone is working on /chat. 

It's Thunderbird's content since Roberto updated it in the last commit
http://hg.mozilla.org/releases/l10n/mozilla-aurora/it/rev/863a549bc624
Attached patch Patch v.2Splinter Review
Here is another patch, against the current aurora. Hopefully this should be better :-)

Gerv
Attachment #662952 - Attachment is obsolete: true
Attachment #662952 - Flags: review?
Thanks Gerv, pushed patch v2 to Aurora
http://hg.mozilla.org/releases/l10n/mozilla-aurora/it/rev/de9d3cca9a28

Not sure how much of it will remain after merge day, for sure fixing bug 793469 before that would be great.

Can you provide us the script you use?
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Looking at the merge you did to central, that should be fine.

I guess that files without license header might switch back to no-license-header, but they'd not switch back to triple license, and that's the key what we're going here for.
I've checked the files related to seamonkey and calendar both on aurora and central and they're ok, both for it and en-US.
If you want, you may edit this bash script to have a fast check:

#! /bin/bash

recursiverm() {
  for d in *; do
    if [ -d "$d" ]; then
      (cd "$d"; recursiverm)
    fi
    echo $d >> /home/iacopo/Desktop/lic
    head -n 3 "$d" | xargs echo -e >> /home/iacopo/Desktop/lic
    echo -e "\n" >> /home/iacopo/Desktop/lic
  done
}

(cd /home/iacopo/sunbird/l10n-aurora/it/extensions; recursiverm)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: