Why not let localizers create XPI from the localized material?
smo
years - one could short-cut the commit-push-nightly build loop. Only 1
- just the final loop - out current N would thus be necessary..
In sl tb30 case these loops have been taking up to a week. A few were
100% unnecessary due to an obvious blunder that could be discovered
and corrected five minutes into the run with a new xpi installed.
Note also that hunting the few remaining screwups and false shortcuts
in such conditions means looking again and again for the proverbial
needle in the haystack.Having a possibility to create an XPI and
install it right away would allow me to keep my finger on the
correction AND see that it´s been executed correctly plus see the
whole context - without waiting for a week for it. Even 24 hours are
eternity compared to "right away".
I am sure that probably "some assembly is required", but we can handle
that. Any comments?
TiA
smo
flod
> Note also that hunting the few remaining screwups and false shortcuts
> in such conditions means looking again and again for the proverbial
> needle in the haystack.Having a possibility to create an XPI and
> install it right away would allow me to keep my finger on the
> correction AND see that it´s been executed correctly plus see the
> whole context - without waiting for a week for it. Even 24 hours are
> eternity compared to "right away".
https://developer.mozilla.org/en/Creating_a_Language_Pack
Anyway, I don't see the point of using an XPI to test your localization.
You can simply download the latest nightly and work on the chrome/sl.jar
of that package: if you're using Windows (but it's probaly possible for
other platforms as well), you can use 7zip's File Manager and change
files without unpacking/repacking the .jar file.
Francesco
Axel Hecht
> Il 21/04/10 12.31, smo ha scritto:
>> Note also that hunting the few remaining screwups and false shortcuts
>> in such conditions means looking again and again for the proverbial
>> needle in the haystack.Having a possibility to create an XPI and
>> install it right away would allow me to keep my finger on the
>> whole context - without waiting for a week for it. Even 24 hours are
>> eternity compared to "right away".
> You can already do that, but it's not that simple
> https://developer.mozilla.org/en/Creating_a_Language_Pack
>
> Anyway, I don't see the point of using an XPI to test your localization.
> You can simply download the latest nightly and work on the chrome/sl.jar
> of that package: if you're using Windows (but it's probaly possible for
> other platforms as well), you can use 7zip's File Manager and change
> files without unpacking/repacking the .jar file.
>
> Francesco
Of course, getting those changes back into the source is much harder then.
But yeah, creating language packs is a snap, just requires sources and
no build environment.
I've started to hack on a python command-line tool to actually get rid
of all the configure etc magic, but it's far from smooth yet. You can
find the "there's still vulcano ash, fly at your own risk" pilot version
at http://bitbucket.org/pike/langpacker/. I didn't check yet if it's
working with the latest compare-locales version either.
Axel
smo
> Il 21/04/10 12.31, smo ha scritto:> Note also that hunting the few remaining screwups and false shortcuts
> > in such conditions means looking again and again for the proverbial
> > needle in the haystack.Having a possibility to create an XPI and
> > install it right away would allow me to keep my finger on the
> > correction AND see that it´s been executed correctly plus see the
> > whole context - without waiting for a week for it. Even 24 hours are
> > eternity compared to "right away".
>
>
> Anyway, I don't see the point of using an XPI to test your localization.
> You can simply download the latest nightly and work on the chrome/sl.jar
> of that package: if you're using Windows (but it's probaly possible for
> other platforms as well), you can use 7zip's File Manager and change
> files without unpacking/repacking the .jar file.
>
> Francesco
Bingo ... much obliged. Given the warning by Axel (nxt entry), I am
cautiously optimistic.
smo
> On 21.04.10 13:02, flod wrote:
>
>
>
> > Il 21/04/10 12.31, smo ha scritto:
> >> Note also that hunting the few remaining screwups and false shortcuts
> >> in such conditions means looking again and again for the proverbial
> >> needle in the haystack.Having a possibility to create an XPI and
> >> install it right away would allow me to keep my finger on the
> >> whole context - without waiting for a week for it. Even 24 hours are
> >> eternity compared to "right away".
> > You can already do that, but it's not that simple
> >https://developer.mozilla.org/en/Creating_a_Language_Pack
>
> > Anyway, I don't see the point of using an XPI to test your localization.
> > You can simply download the latest nightly and work on the chrome/sl.jar
> > of that package: if you're using Windows (but it's probaly possible for
> > other platforms as well), you can use 7zip's File Manager and change
> > files without unpacking/repacking the .jar file.
>
> > Francesco
>
> Of course, getting those changes back into the source is much harder then.
>
> But yeah, creating language packs is a snap, just requires sources and
> no build environment.
>
> I've started to hack on a python command-line tool to actually get rid
> of all the configure etc magic, but it's far from smooth yet. You can
> find the "there's still vulcano ash, fly at your own risk" pilot version
> working with the latest compare-locales version either.
>
> Axel
well, who put all that ash in the air in the first place, Axel;P
keep us posted... this could spare us a lot of time and errors...
Tim Babych
> If one could do it - as all the add-in programmers have been doing for
> years - one could short-cut the commit-push-nightly build loop. Only 1
> - just the final loop - out current N would thus be necessary..
>
Hello. I have been living in the environment you describe for years, it
surprises me that someone is still relying on nigtlys.
My directory structure is
~/recommitter/comm/src - clone of http://hg.mozilla.org/mozilla-central/
/en - contains symlinks to the l10n, e.g.
/en/browser -> http://hg.mozilla.org/mozilla-central/
/uk - clone of http://hg.mozilla.org/l10n-central/uk/
/build/fx - the directory for building Firefox
in src lives a file .mozconfig.firefox , containing:
ac_add_options --disable-compile-environment
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../build/fx
ac_add_options --with-l10n-base=/home/tim/recommitter/comm
ac_add_options --enable-application=browser
ac_add_options --enable-official-branding
In ~/bin I have regenerate-comm.sh , containing:
DIR=~/recommitter/comm
cd $DIR/src
cp .mozconfig.firefox .mozconfig # this and next line are needed only
make -f client.mk configure # when you need to swap .mozconfigs
cd $DIR/build/fx/browser/locales
make langpack-uk
When those things set, all you have to do to get new xpi is run te
script regenerate-comms.sh XPI will appear in
recommitter/build/fx/dist/install ,
the very same as tinderbox itself would generate.
One can even save the time on actual reinstallatio of the package, just
go to your profile and replace directory of the l10n extension with
symlink to xpi-stage/subdir. E.g
tim@denmark:~/.mozilla/firefox/nightler/extensions$ ls -l
langp...@firefox.mozilla.org ->
/home/tim/recommitter/comm/build/fx/dist/xpi-stage/locale-uk
You can ping me (tymofiy) at #l10n, I would be happy to help you set up
the environment.
smo
> Anyway, I don't see the point of using an XPI to test your localization.
> You can simply download the latest nightly and work on the chrome/sl.jar
> of that package: if you're using Windows (but it's probaly possible for
> other platforms as well), you can use 7zip's File Manager and change
> files without unpacking/repacking the .jar file.
>
> Francesco
It really works (sigh). Of course I can expect reactions like "Of
course! What makes you think it will not?!" or "Of course! You mean
you did not know it?". No I did not, it is just that nobody told me
(sg) and I did not ask (ssg).
I can just talk in my name and in the name of my TB30 l10n group: we
would be finished significantly sooner, if this were known to us. It
would also mean a significant relief for Simon, because he would not
be pestered with errors that are evident right away in the product. Of
course this does not work, if the code involving strings changes, but
then its not the localization thats on the critical path, its the
developers (again;)
If I look at our (sl TB30) timeline for the last month, we were green
(with a lot of help from Simon, much appreciated!) on the 1st of
April, blundered on the 6th and turned green again on the 20th. Been
waiting for yet-another-last green since morning 22nd. Reminds me of
those "How many Irish/Ostfriesen/Belges/Newfies does it take to screw
in the bulb"-jokes.
I can vouch for my group that we could do significantly better than
that time- and qualitywise: I would guesstimate a week, maybe ten
days, if I had known about this hack before. In other words half of
the time it has taken to get that far. And I think we are not the only
ones.
Lets see how it works on 3.1. But not yet - we need 3.0 released.
Takes time;).
regards
smo
smo
> 21.04.10 13:31, smo написав(ла):
>
> > If one could do it - as all the add-in programmers have been doing for
> > years - one could short-cut the commit-push-nightly build loop. Only 1
> > - just the final loop - out current N would thus be necessary..
>
> Hello. I have been living in the environment you describe for years, it
> surprises me that someone is still relying on nigtlys.
>
Hey, somebody has to play the stupid in this game.
I just did the 7-zip trick, suggested by Francesco, and it works. It's
so simple it's close to insulting (sg).
Your information however may still come handy, same for your handle on
IRC (g).
regards and thanks
smo
Axel Hecht
Hi Vito,
probably a timing issue, we're pointing new localizers to
https://developer.mozilla.org/en/Create_a_new_localization#Building_and_testing
now, which has a section on how to test locally. I'm not sure if I found
a few pitfalls not explicitly mentioned, I'll need to reread that thing.
Axel
smo
> now, which has a section on how to test locally. I'm not sure if I found
> a few pitfalls not explicitly mentioned, I'll need to reread that thing.
>
> Axel
Hi Axel:
No problem, I know we're all sitting on the fence right now. It's only
that this trick would spare (quite) some time, not just us, but Simon
as well (well, in hindview everything is SO obvious;)
Note that TBsl is still at the 3.0x stage. I would like to have that
released before we take the 3.1 on - there's be minor revisions
waiting for us there for sure. Then, if necessary, we can take the
subject up again.
regards and thanks
smo