Autoupdate for applications and extensions outside Mozilla sites for unoffical locales
Michael Wolf
I create unofficial locales for Firefox, Thunderbird and SeaMonkey.
These are:
Esperanto - SM, TB
Upper Sorbian - FX, SM, TB
Lower Sorbian - FX, TB
I'd like to offer autoupdates both for the applications and the extensions.
But, as my locales are not on Mozilla sites, I must anyhow cause the
update routine to update from my sites and not from Mozilla sites.
What I have to do for that?
Is it possible to make it from a local program installation or is it
possible from Mozilla sites only?
Which files I need? Are needed files form Mozilla sites?
What I have to change in needed files?
Thanks in advance
Regards,
Michael
Eduardo Trápani
> These are:
>
> Esperanto - SM, TB
Great! Where can I download them from?
Eduardo.
Michael Wolf
Hi Eduardo,
you can download them from:
http://seamonkey.eozilla.de
http://thunderbird.eozilla.de
Regards,
Michael
Jesper Kristensen
Michael Wolf
> See https://developer.mozilla.org/en/install_manifests#updateURL
Hi Jesper,
thank you very much.
Your link seems to deal with add-on updates only. I'll read over that page.
Regards,
Michael
Axel Hecht
I don't think that distributing your own builds and software updates
just so is the right thing to do. The language packs are fine, of course.
But for redistributing modified binaries, please follow
http://www.mozilla.com/en-US/about/partnerships.html
Axel
Michael Wolf
> Hi Michael,
>
> I don't think that distributing your own builds and software updates
> just so is the right thing to do. The language packs are fine, of course.
>
> But for redistributing modified binaries, please follow
> http://www.mozilla.com/en-US/about/partnerships.html
>
Fine. :-(
Does this mean I am not allowed more to create binaries? I do this
already for some years and I think you know that. I do not change any
source code but customize some settings that are outside the language
pack. Strictly speaking I change only the locale in firefox.js and
firefox-l10.js, and in firefox.js I change the variable "%LOCALE%" to
"de" in Sorbian binaries that Sorbian can read the German translations
instead of the English texts. I cannot use %LOCALE% because those
Mozilla pages exist neither in Upper Sorbian nor in Lower Sorbian. And
not all pages are in Esperanto, either. Otherwise error would come that
page does not exist.
And to avoid errors in update process I can do 2 things only: Disable
updating or customize update to my sites www.sorbzilla.de resp.
www.eozilla.de
Regards,
Michael
Axel Hecht
Hi Michael,
we can't OK your distribution here in the newsgroup, you'll need to
follow up with the folks who review our partner builds.
I can only discourage you from trying to maintain your own builds. While
the actual generation of bits shouldn't be all that hard, serving the
updates is something that's not pretty. Not just that you'd need to do
it in a particular timeframe (not before, but not too long after
either). Also, the software we use to serve the updates is our most sad
kitten in the zoo.
I'd strongly encourage you to work on having the language packs up and
smooth, and not invest in complete builds.
Axel
John Wilcock
> I can only discourage you from trying to maintain your own builds. While
> the actual generation of bits shouldn't be all that hard, serving the
> updates is something that's not pretty. Not just that you'd need to do
> it in a particular timeframe (not before, but not too long after
> either). Also, the software we use to serve the updates is our most sad
> kitten in the zoo.
Without knowing the history of Michael's unofficial localisations, the
first question that comes to mind is what is stopping them from being
promoted to official localisations, thereby sidestepping all the build
problems entirely?
--
John
Michael Wolf
>
> I can only discourage you from trying to maintain your own builds. While
> the actual generation of bits shouldn't be all that hard, serving the
> updates is something that's not pretty.
Not just that you'd need to do
> it in a particular timeframe (not before, but not too long after
> either). Also, the software we use to serve the updates is our most sad
> kitten in the zoo.
It's exactly the reason why I maintain own builds **unofficially**. I am
alone who does the work. I don't need create a new localization for
every small security update. I create langpacks and localized builds for
years regularly. My last translations for Firefox into Upper Sorbian and
Lower Sorbian are für Fx 5.0. Those are current versions. Fx 5.0.1 is
important for MacOS X only - for this OS I do not create localized builds.
And, as already said, what I customize is the locale code and some URL
that they the links remain valid. That are some changes in the files
firefox.js and firefox-l10n.js only. What's the problem there? And I
create only packed versions, no installs.
Well, I can disable autoupdate. For URL to Mozilla sites with the
variable %LOCALE% it is perhaps possible that I can translate them if
those are not too much and too often updated. Otherwise I use the German
translations for my Sorbian builds - for Esperanto I do not change this
variable.
>
> I'd strongly encourage you to work on having the language packs up and
> smooth, and not invest in complete builds.
I really do those small changes I mentioned above. There is no big
investmen in work.
Regards
Michael
Justin Wood (Callek)
> Eduardo Tr�pani napisa:
As the SeaMonkey release engineer, and member of the SeaMonkey Council,
I have to say, I'm not a fan of this.
You mentioned in other posts, that You do *not* create updates for
security releases regularly. You also mentioned that you are basically
doing just locale packs anyway but modify a few prefs. (Like making sure
Firefox [de] webpages are shown)
I visited that website for SeaMonkey and noticed you are woefully behind
in our updates.
1'st you're using SeaMonkey 2.0.10 which is not the latest 2.0 version,
so has Security Vulnerabilities for your users that are old and high
profile (even Firefox 3.5.current has better security than SeaMonkey 2.0.10)
2'nd SeaMonkey's latest (and only supported) version is 2.2, and we have
2.3 coming out within 2 weeks.
Your efforts would be much better placed doing langpacks, and having
SeaMonkey and Firefox users download the appropriate build for a
web-language they can understand (de for the case you mention above) and
use the langpack you provide, that you can update even on AMO.
It allows your users to stay secure, without impacting the openness of
the web, their choice, or their system stability.
With my SeaMonkey hat on, please either only provide langpacks, or
update your builds to our latest available version[s] to protect your users.
The stability of SeaMonkey and Firefox is impacted by not providing
these updates in the branded builds you distribute, even if we don't
endorse them. And that user perception really does make a difference.
--
~Justin Wood (Callek)
Michael Wolf
> As the SeaMonkey release engineer, and member of the SeaMonkey Council,
> I have to say, I'm not a fan of this.
>
> You mentioned in other posts, that You do *not* create updates for
> security releases regularly. You also mentioned that you are basically
> doing just locale packs anyway but modify a few prefs. (Like making sure
> Firefox [de] webpages are shown)
>
> I visited that website for SeaMonkey and noticed you are woefully behind
> in our updates.
>
> 1'st you're using SeaMonkey 2.0.10 which is not the latest 2.0 version,
> so has Security Vulnerabilities for your users that are old and high
> profile (even Firefox 3.5.current has better security than SeaMonkey
> 2.0.10)
2.0.12 etc. I didn't because I hoped to finish my translation for SM
2.1. earlier. Meanwhile SM 2.2. has bee released.
Well, it may be that FX 3.5 have already had a better security than SM
2.0.10. But you have been released SM 2.0.10 anyway. The security
vulnerabilities have been already in SM 2.0.10 (or other releases) when
you released it. You are a member of the SM team and not of the Firefox
team, so it's in the first place your business to release versions
without vulnerabilities.
>
> 2'nd SeaMonkey's latest (and only supported) version is 2.2, and we have
> 2.3 coming out within 2 weeks.
I am working in translating SM 2.2 to Esperanto and Upper Sorbian. I do
not have any influence to the release rhythm, I'll do my best but the
problem are not the builds themselves, it's the language pack. When
there is a big version jump, I have to translate a lot, no matter if I
make builds or langpacks only. Those few changes in the respective js
files in defaults/pref/ don't make a big temporal difference.
>
> Your efforts would be much better placed doing langpacks, and having
> SeaMonkey and Firefox users download the appropriate build for a
> web-language they can understand (de for the case you mention above) and
> use the langpack you provide, that you can update even on AMO.
> It allows your users to stay secure, without impacting the openness of
> the web, their choice, or their system stability.
That's the decision of the users themselves. I don't have any influence
on it. May be they do so like you wrote. I additionally offer them 2
packed builds only. I'm sure if the users want to have the most current
version they will use the most current version, Sorbians probably in
German and esperantists in their national language. I do not and cannot
force users use my older versions.
And what's with Firefox and Thunderbird? On the official Mozilla sites
afaik no langpacks are offered - only builds! Only on the FTP sites
(ftp://ftp.mozilla.org) you can find langpacks.
>
> With my SeaMonkey hat on, please either only provide langpacks, or
> update your builds to our latest available version[s] to protect your
> users.
I repeat once more: Whether with builds or with langpacks only, the work
is the same because the most work to do is in the langpack. What I can
promise is that I can prepare more builds for security updates where the
langpack didn't change or changed not much only. But that's not a matter
if build or no build. It's a matter of frequency to provide localized
builds and langpacks.
>
> The stability of SeaMonkey and Firefox is impacted by not providing
> these updates in the branded builds you distribute, even if we don't
> endorse them. And that user perception really does make a difference.
I repeat: I do not have much influence on which version users are using.
I think, even if there are localized builds that are up-to-date - and I
do my best that they are so - the final decision which version a user is
using the user himself makes.
Regards,
Michael
Justin Wood (Callek)
> Well, it may be that FX 3.5 have already had a better security than SM
> 2.0.10. But you have been released SM 2.0.10 anyway. The security
> vulnerabilities have been already in SM 2.0.10 (or other releases) when
> you released it. You are a member of the SM team and not of the Firefox
> team, so it's in the first place your business to release versions
> without vulnerabilities.
Our latest SeaMonkey 2.0.x is of the same security support as the Latest
Firefox 3.5.x fwiw. We *do* match firefox support for security.
And yes, if you can't maintain doing *builds* for branches, you
shouldn't distribute *builds* at all [imo]
--
~Justin Wood (Callek)
(more thorough reply to your post when I've had time to excise some of
my frustrations so I don't implore the wrong tone in my message)
Michael Wolf
> And yes, if you can't maintain doing *builds* for branches, you
> shouldn't distribute *builds* at all [imo]
I do it alone and it's a matter of time above all. Once more: the main
work is translating the language pack, not maintaining builds. I can
make available build for more security updates, but I can't always keep
pace with the release rhythm of official releases. Especially, with the
new Firefox release rhythm, although I don't know yet if this is a
matter of numbering only or if there will be really big version jumps.
Michael
Axel Hecht
Michael, there's no point in re-iterating over this.
You've never been allowed to distribute modified builds with official
branding, and you're not now -- unless you get an official permission to
do so via the process that's been outlined.
You've provided us with a series of good arguments why we shouldn't let
you do that, either.
Axel
Michael Wolf
> You've never been allowed to distribute modified builds with official
> branding, and you're not now -- unless you get an official permission to
> do so via the process that's been outlined.
>
> You've provided us with a series of good arguments why we shouldn't let
> you do that, either.
No, imho I provided you a series of good arguments that I can do it.
The only reason I must accept is that I need a permission - according to
the link about partnership you provided. I accept unwillingliy - but I
accept it.
Michael