414939 - Pull dates from localized strings in order to allow copyrights to be updated without relocalizing strings and fix completely unrelated unreported bugs about spaces in XUL and XHTML files which happen to have years in them

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Al Billings [:abillings - ex-MoCo]]

For localized builds, the copyright in Branch is set to "2006" even though it is "2008" in en-US. We need to pull the copyright out of the localized strings so the copyright date can be updated without forcing relocalizations just for that change.

Comment 1

[Daniel Veditz [:dveditz]]

"Branch" == MOZILLA_1_8_BRANCH, but since the string in question is the one from the about page it's probably Firefox specific strings. Thunderbird probably has the same problem, in a different string somewhere else :-(

Comment 2

[Daniel Veditz [:dveditz]]

Sorry, bugzilla auto-reassign strikes again. This should be something for Axel
to worry about.

An alternate approach would be to go fix all 40+ locales by hand. Maybe in the
short run that's less work for FF2 anyway. I'd be ok with that as far as
this bug is concerned, but maybe for FF3 you want to plan ahead so we don't run
into the same problem again.

Comment 3

[Axel Hecht [:Pike]]

I don't have time to fix this.

Again, it has been decided over and over and over that this is not a problem for Fx2, at least I have never seen an argument against that.

Fx3 is string frozen, and given that we resolved this issue for releases with a finite lifetime, this had to be low cost.

Note, even if we had a single entity to pull the copyright date from, that doesn't make it trivial to fix in general. Though probably for 95%.

Addition, the biggest chunk is in-product help, AFAICT, which might actually end up being CVS removed for Fx3.

Comment 4

[Al Billings [:abillings - ex-MoCo]]

So we just lived with the copyright being set to 2006?

Comment 5

[Axel Hecht [:Pike]]

According to Gerv, copyright sticks for, IIRC, 70 years, thus it's not a problem for branches with a finite lifetime.

Comment 6

[Phil Ringnalda (:philor)]

> Though probably for 95%.

98%, last time I thought about it - 57 of 58 1.8 locales use the same numerals.

It would help with these various copyright date bugs if before we go off on how, we reach a decision about why.

My personal reason has always been "it looks crappy and abandoned, particularly when it's only non-en-US running behind." The discussion always seems to be about legal reasons, for which my IANAL conclusion was that so long as we'll be claiming we first publish in the US, that only matters if we're going to go to court in Andorra, Laos, Saudi Arabia, Turkmenistan or Uzbekistan, and for that case, claiming UCC coverage rather than Berne, the required notification is "(c) {year of first publication} {identifiable name of copyright holder}" making the end of the range either moot or actually incorrect to use.

But, if we're talking about fixing it for legal reasons, rather than because it looks like we're ignoring non-en-US, then someone needs to talk to a lawyer, rather than making decisions based on bug comments by a bunch of non-lawyers.

Comment 9

[Michael Ryan]

Should this block bug 470179?

Comment 10

[Phil Ringnalda (:philor)]

Attachment: Fix v.1

No, it doesn't need to block something that's already done, it needs a patch, and nothing but a patch.

I skipped doing the third remaining set of copyright years, in help/welcome.xhtml, both because it seemed silly to add another entity for a single instance of 2003-200x, and because it's actually unused: SeaMonkey is the only thing building help at the moment, and they use a different page. If someone wants to do a mostly-suite patch for &helpProjectYears;, they can always pick up that unused one at the same time.

If I counted right, we're now up to 70 locales that can use this, and 5 that can't, either because of digits or (unless I just got confused by the mixed-content display) because it's in the wrong order. Not perfect, but I'm still hoping it will result in a more than 93% reduction in bugs filed about non-en-US locales being abandoned-looking.

Comment 11

[Phil Ringnalda (:philor)]

Attachment: Fix v.2

You'd think that having my update patch for 2009 and an email to myself reminding me about credits.xhtml both open in front of me would be enough to have made me include it on the first try, wouldn't you?

Comment 12

[Axel Hecht [:Pike]]

Comment on attachment 383625 [details] [diff] [review]
Fix v.2

TBH, I don't like this patch. The combination of fooPre and fooAfter is as awkward as is the combination of bar1 with barB. This is gonna make this even more awkward than it already is for new localizations.

The hard-coding of ' ' in the file causes some bugs, IIRC, at least for some languages.

I wonder if we should review all bugs in this area and rewrite the page to address those, plus some scripting to rewrite the existing locales to the new markup. Bug 433890 comes up on a brief search, I recall some bug about a space before the ) introducing some wrapped lines, too.

I also wonder if we should allow for locales to add a DTD with an overloaded locale-specific file, somewhat like we do for netErrorApp.dtd. Then the arab and indic script locales could at least fix the numbers in their script in a central place.

Comment 13

[Phil Ringnalda (:philor)]

Attachment: Fix v.3

(In reply to comment #12)
> TBH, I don't like this patch. The combination of fooPre and fooAfter is as
> awkward as is the combination of bar1 with barB. This is gonna make this even
> more awkward than it already is for new localizations.

TBH, I'd rather get a catheter inserted by a strung out junkie who hasn't washed for years than touch l10n, which has never given me anything but vagueness followed by being yelled at.

However, fixed, by making a clear spot to version both pairs of before and after strings, with as little pointless changing of keys without changing the content as I could manage.

> The hard-coding of ' ' in the file causes some bugs, IIRC, at least for some
> languages.

I wasn't able to find any sign of those bugs being filed: I'd recommend suggesting that someone affected, who knows what spaces you mean and what problem they cause, file a bug. If they can't just fix it themselves, I might even be willing, in a separate bug that was about doing so and made it clear what it was doing and why.

> I wonder if we should review all bugs in this area and rewrite the page to
> address those, plus some scripting to rewrite the existing locales to the new
> markup. Bug 433890 comes up on a brief search, I recall some bug about a space
> before the ) introducing some wrapped lines, too.

Bug 433890 is about some English text in credits.xhtml, not about anything localized or related to what I'm touching. Bug 471838 is about the XUL, the way that a <label> in a <description> doesn't act like an inlineish thing, not about the "(" or anything else related to the string content.

> I also wonder if we should allow for locales to add a DTD with an overloaded
> locale-specific file, somewhat like we do for netErrorApp.dtd. Then the arab
> and indic script locales could at least fix the numbers in their script in a
> central place.

I've never heard anyone suggest that having the range of years appear in two different DTDs was a problem that anyone wanted to have solved. The problem I'm trying to solve is that you have said repeatedly that you do not want to allow changes to locales on stable branches to update the years, while dveditz has said repeatedly that he does want to update the years in en-US on stable branches, and then users of localized builds object to the way their builds look forgotten and out of date. Are you saying that you want this patch to be much more complicated because you are now going to allow those five locales to make stable branch changes, as long as it's just those five and not all seventy five, and they make a change to a single line in a single DTD instead of making changes to two lines in two DTDs? Otherwise, I don't see how that's a part of this bug.

Comment 14

[Axel Hecht [:Pike]]

Comment on attachment 389259 [details] [diff] [review]
Fix v.3

Sorry, this is not getting better.

There are a few problems with both original files, and if we touch this at all, we should actually fix the files, and not add noise to particular details.

Most prominently, there are " " inside the xul and the xhtml, and that's bad. Those belong into the entities, which basically changes all of them. And then we can use consistent entity names again, instead of asking new localizers to reverse engineer the history of those files.

The impact on localizers can be minimized with taking a good look at the right patch, and do some automagically rewriting for all locales. That's something that one of us l10n-drivers can do as a follow up to the patch, but before actually landing.

Comment 15

[Phil Ringnalda (:philor)]

Dates in copyright strings? What dates? What copyright strings? First fixed by removing all the dates, then refixed by removing all the strings.