As a heads up to all l10n contributors who were a part of the Firefox 1.0 release and those who are working to be a part of our 1.0.1 release, we'll be transitioning our l10n build systems so they generate 1.0.1 builds this weekend. This will conclude our automated builds of Firefox 1.0. When the transition is complete, new nightly builds will begin appearing in: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1-l10n/ If your localization has a released Firefox 1.0, you should not need to make any changes for the 1.0.1 release. At this time, no UI string changes are planned -- and we want to avoid making any! :) Since you'll basically get a Firefox 1.0.1 "for free," please proceed to work in CVS on the trunk where localization work on the next major Firefox release is making good progress. If your localization has not yet released Firefox 1.0, you will continue to commit changes on the Aviary 1.0 branch though you will need to shift your attention away from Firefox 1.0 to Firefox 1.0.1. As a reminder, this branch tag is: AVIARY_1_0_20040515_BRANCH Gandalf and Axel have been given the power to grant l10n approvals for this drive to Firefox 1.0.1. Where there's any question about whether a change should land, Asa and myself will help out. A new Bugzilla flag 'approval-l10n' has been added so that l10n-specific patches can be brought to Gandalf's and Axel's attention as candidates for landing. They will reuse this flag as the need arises. So, for those of you who haven't released a Firefox 1.0, are working on a localization for 1.0.1, and haven't been in touch, the l10n community needs to hear from you. Please reply to this thread and announce your project's plans. There's still enough time for your locale to land, get official sign-off, and be a part of the upcoming 1.0.1 release in the "first wave." The main steps needed to get official release status for 1.0.1 are: - Initial check-in of a localization, reviewed by Gandalf. - QA of the resulting builds by the localization team, fixes requiring approval by Gandalf or Axel to land in CVS. ** Do not check-in without approval! ** Again, please use the approval-l10n flag in Bugzilla. - Trademark sign-off, QA, and release by Mozilla Foundation engineers. To get sign off, a new bug must be filed in Bugzilla under your localization's component and assigned to Asa. Set the 'certification-l10n' flag on the bug to signify the locale is ready to be tested by MoFo QA. Any problems encountered during this phase will have separate bugs filed assigned to the locale's owner. Please take care of the major bits of the trademarks [1]. - Once your build clears QA, the QA team will set the 'release-l10n' flag to signify to me that the build is ready to be released and I will go into action to make the files ready for distribution from the web and FTP site. Again, all of the above only applies to locales not yet having an official Firefox 1.0 build. If you already had a Firefox 1.0 release, you should continue to work on the trunk. At Axel's request, localizations should translate: http://www.mozilla-europe.org/en/products/firefox/start/central.txt http://www.mozilla-europe.org/en/products/firefox/start/get-involved.txt http://www.mozilla-europe.org/en/products/firefox/start/about.txt Send your results (without BOM, UTF-8 encoded) to startpages@mozilla-europe.org. [1] Trademark stuff: - bookmarks.html needs to stick to the format of the en-US version. - Links should be localized, if a link cannot be localized, make sure that the user expects an English site. - Search engines should be localized. The list should correspond to the en-US build, taking into account the order of search engines in the en-US build. If you need clarification, ask Rafael Ebron (rebron on irc). Both he and Axel will look closely at the google and yahoo search engine plugins, including their icons. They'll be able to provide insight into how to proceed. Axel and Gandalf helped to lay down a large part of the process for managing 1.0.1 check-ins. Thanks to them both for their hard work and to the l10n community for your on-going support of the Mozilla project! Chase
![]() |
0 |
![]() |
Hi! The pt-PT team has been providing langpacks for Firefox 1.0, and this week I've been testing the first pt-PT builds to come out of the MF build system. I have some changes to strings in the installer (which I'm testing for the first time) and some minor changes to the rest of the localization files (nothing big, just fixed typos and such). So, my question is: while the installer changes are important, the others are minor and can wait for me to start working on the trunk. But, what are the chances of getting approval on all of them? (Remember, they are minor and I've been testing them myself for weeks). I ask this because I'm unsure about the approval policy, and even if the policy states that only important stuff goes in, I wan't to know if that also applies to a first-time release. Carlos Rodrigues, Firefox pt-PT Chase Phillips wrote: > As a heads up to all l10n contributors who were a part of the Firefox > 1.0 release and those who are working to be a part of our 1.0.1 release, > we'll be transitioning our l10n build systems so they generate 1.0.1 > builds this weekend. This will conclude our automated builds of Firefox > 1.0. When the transition is complete, new nightly builds will begin > appearing in: > > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1-l10n/ > > > If your localization has a released Firefox 1.0, you should not need to > make any changes for the 1.0.1 release. At this time, no UI string > changes are planned -- and we want to avoid making any! :) Since you'll > basically get a Firefox 1.0.1 "for free," please proceed to work in CVS > on the trunk where localization work on the next major Firefox release > is making good progress. > > If your localization has not yet released Firefox 1.0, you will continue > to commit changes on the Aviary 1.0 branch though you will need to shift > your attention away from Firefox 1.0 to Firefox 1.0.1. As a reminder, > this branch tag is: > > AVIARY_1_0_20040515_BRANCH > > Gandalf and Axel have been given the power to grant l10n approvals for > this drive to Firefox 1.0.1. Where there's any question about whether > a change should land, Asa and myself will help out. A new Bugzilla flag > 'approval-l10n' has been added so that l10n-specific patches can be > brought to Gandalf's and Axel's attention as candidates for landing. > They will reuse this flag as the need arises. > > So, for those of you who haven't released a Firefox 1.0, are working on > a localization for 1.0.1, and haven't been in touch, the l10n community > needs to hear from you. Please reply to this thread and announce your > project's plans. There's still enough time for your locale to land, get > official sign-off, and be a part of the upcoming 1.0.1 release in the > "first wave." > > The main steps needed to get official release status for 1.0.1 are: > > - Initial check-in of a localization, reviewed by Gandalf. > - QA of the resulting builds by the localization team, fixes requiring > approval by Gandalf or Axel to land in CVS. ** Do not check-in > without approval! ** Again, please use the approval-l10n flag in > Bugzilla. > - Trademark sign-off, QA, and release by Mozilla Foundation engineers. > To get sign off, a new bug must be filed in Bugzilla under your > localization's component and assigned to Asa. Set the > 'certification-l10n' flag on the bug to signify the locale is ready > to be tested by MoFo QA. Any problems encountered during this phase > will have separate bugs filed assigned to the locale's owner. > Please take care of the major bits of the trademarks [1]. > - Once your build clears QA, the QA team will set the 'release-l10n' > flag to signify to me that the build is ready to be released and I > will go into action to make the files ready for distribution from the > web and FTP site. > > Again, all of the above only applies to locales not yet having an > official Firefox 1.0 build. If you already had a Firefox 1.0 release, > you should continue to work on the trunk. > > At Axel's request, localizations should translate: > > http://www.mozilla-europe.org/en/products/firefox/start/central.txt > http://www.mozilla-europe.org/en/products/firefox/start/get-involved.txt > http://www.mozilla-europe.org/en/products/firefox/start/about.txt > > Send your results (without BOM, UTF-8 encoded) to > startpages@mozilla-europe.org. > > [1] Trademark stuff: > - bookmarks.html needs to stick to the format of the en-US version. > - Links should be localized, if a link cannot be localized, make sure > that the user expects an English site. > - Search engines should be localized. The list should correspond to > the en-US build, taking into account the order of search engines in > the en-US build. If you need clarification, ask Rafael Ebron (rebron > on irc). Both he and Axel will look closely at the google and yahoo > search engine plugins, including their icons. They'll be able to > provide insight into how to proceed. > > Axel and Gandalf helped to lay down a large part of the process for > managing 1.0.1 check-ins. Thanks to them both for their hard work and > to the l10n community for your on-going support of the Mozilla project! > > Chase
![]() |
0 |
![]() |
Carlos Rodrigues napisaĆ(a): > So, my question is: while the installer changes are important, the > others are minor and can wait for me to start working on the trunk. But, > what are the chances of getting approval on all of them? (Remember, they > are minor and I've been testing them myself for weeks). Basicly, if your language was not released for 1.0, you're free to make any improvements. That's because such builds were not yet verified and signed by QA team in Mozilla Foundation and this will be made later. So feel free to make any changes but: a) sooner is better, b) lesser is better. Both rules will make approval process going faster :) Making sure that me or Pike are CCed to such bug is also good idea. Greetings Zbigniew Braniecki -- AviaryPL
![]() |
0 |
![]() |
Zbigniew Braniecki escribi=C3=B3: >=20 > Basicly, if your language was not released for 1.0, you're free to make= > any improvements. And what about if the language was indeed released but minor changes were detected and fixed later in community releases, like it has been the case with es-ES? Is there any chance that FF 1.0.1 locales can benefit of feedback from 1.0 users? TIA --=20 If it's true that we are here to help others, then what exactly are the OTHERS here for?
![]() |
0 |
![]() |
> So, for those of you who haven't released a Firefox 1.0, are working on > a localization for 1.0.1, and haven't been in touch, the l10n community > needs to hear from you. Please reply to this thread and announce your > project's plans. There's still enough time for your locale to land, get > official sign-off, and be a part of the upcoming 1.0.1 release in the > "first wave." I hope the mk-MK translation will be approved in time for 1.0.1. I beleive its ready and I have succesfully tested a Linux build. The translation is currently been reviewed by MoFO here: https://bugzilla.mozilla.org/show_bug.cgi?id=276345 but I wonder what's going on, since there's not been any changes in the recent 7 days. But, in the mean time I'd ask anyone if he could make a windows build so that we know that it works as well? -- damjan
![]() |
0 |
![]() |
Hello! Thanks for the heads up and the instructions. We in the Welsh (cy-GB) team are QA'ing the latest builds at the moment and are confident that we'll make it for 1.0.1 One question in the meantime concerning bookmarks.html. Can we completely localise the default news RSS feed? We have translated the title for the entry in bookmarks.html but not the actual link itself. I don't know how the fxfeeds.mozilla.org redirection works for other languages. But at the moment, in the Welsh Firefox you get the English BBC Worldwide news. The BBC however does have a Welsh language news feed http://news.bbc.co.uk/rss/welsh/newyddion/rss091.xml which we would naturally like to have in place instead of English. Apologies if this is a silly question and something we should have been doing anyway. Hwyl, Cheers, Dewi. Ysgrifennodd Chase Phillips: > As a heads up to all l10n contributors who were a part of the Firefox > 1.0 release and those who are working to be a part of our 1.0.1 release, > we'll be transitioning our l10n build systems so they generate 1.0.1 > builds this weekend. This will conclude our automated builds of Firefox > 1.0. When the transition is complete, new nightly builds will begin > appearing in: > > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1-l10n/ > > > If your localization has a released Firefox 1.0, you should not need to > make any changes for the 1.0.1 release. At this time, no UI string > changes are planned -- and we want to avoid making any! :) Since you'll > basically get a Firefox 1.0.1 "for free," please proceed to work in CVS > on the trunk where localization work on the next major Firefox release > is making good progress. > > If your localization has not yet released Firefox 1.0, you will continue > to commit changes on the Aviary 1.0 branch though you will need to shift > your attention away from Firefox 1.0 to Firefox 1.0.1. As a reminder, > this branch tag is: > > AVIARY_1_0_20040515_BRANCH > > Gandalf and Axel have been given the power to grant l10n approvals for > this drive to Firefox 1.0.1. Where there's any question about whether > a change should land, Asa and myself will help out. A new Bugzilla flag > 'approval-l10n' has been added so that l10n-specific patches can be > brought to Gandalf's and Axel's attention as candidates for landing. > They will reuse this flag as the need arises. > > So, for those of you who haven't released a Firefox 1.0, are working on > a localization for 1.0.1, and haven't been in touch, the l10n community > needs to hear from you. Please reply to this thread and announce your > project's plans. There's still enough time for your locale to land, get > official sign-off, and be a part of the upcoming 1.0.1 release in the > "first wave." > > The main steps needed to get official release status for 1.0.1 are: > > - Initial check-in of a localization, reviewed by Gandalf. > - QA of the resulting builds by the localization team, fixes requiring > approval by Gandalf or Axel to land in CVS. ** Do not check-in > without approval! ** Again, please use the approval-l10n flag in > Bugzilla. > - Trademark sign-off, QA, and release by Mozilla Foundation engineers. > To get sign off, a new bug must be filed in Bugzilla under your > localization's component and assigned to Asa. Set the > 'certification-l10n' flag on the bug to signify the locale is ready > to be tested by MoFo QA. Any problems encountered during this phase > will have separate bugs filed assigned to the locale's owner. > Please take care of the major bits of the trademarks [1]. > - Once your build clears QA, the QA team will set the 'release-l10n' > flag to signify to me that the build is ready to be released and I > will go into action to make the files ready for distribution from the > web and FTP site. > > Again, all of the above only applies to locales not yet having an > official Firefox 1.0 build. If you already had a Firefox 1.0 release, > you should continue to work on the trunk. > > At Axel's request, localizations should translate: > > http://www.mozilla-europe.org/en/products/firefox/start/central.txt > http://www.mozilla-europe.org/en/products/firefox/start/get-involved.txt > http://www.mozilla-europe.org/en/products/firefox/start/about.txt > > Send your results (without BOM, UTF-8 encoded) to > startpages@mozilla-europe.org. > > [1] Trademark stuff: > - bookmarks.html needs to stick to the format of the en-US version. > - Links should be localized, if a link cannot be localized, make sure > that the user expects an English site. > - Search engines should be localized. The list should correspond to > the en-US build, taking into account the order of search engines in > the en-US build. If you need clarification, ask Rafael Ebron (rebron > on irc). Both he and Axel will look closely at the google and yahoo > search engine plugins, including their icons. They'll be able to > provide insight into how to proceed. > > Axel and Gandalf helped to lay down a large part of the process for > managing 1.0.1 check-ins. Thanks to them both for their hard work and > to the l10n community for your on-going support of the Mozilla project! > > Chase
![]() |
0 |
![]() |
Chase Phillips wrote: > So, for those of you who haven't released a Firefox 1.0, are working on > a localization for 1.0.1, and haven't been in touch, the l10n community > needs to hear from you. Please reply to this thread and announce your > project's plans. There's still enough time for your locale to land, get > official sign-off, and be a part of the upcoming 1.0.1 release in the > "first wave." We have a completed Xhosa build that we would like to include in 1.0.1 (as I mentioned on IRC). I will check on the status of other South African languages and reply again if there are any more. The main delay here is migrating our xpi - we haven't been using Mozilla Translator, haven't done 0.9 and the auto-migration tool didn't like our xpi, so I need to find the details of where to move the files etc. > The main steps needed to get official release status for 1.0.1 are: > > - Initial check-in of a localization, reviewed by Gandalf. > - QA of the resulting builds by the localization team, fixes requiring > approval by Gandalf or Axel to land in CVS. ** Do not check-in > without approval! ** Again, please use the approval-l10n flag in > Bugzilla. > - Trademark sign-off, QA, and release by Mozilla Foundation engineers. > To get sign off, a new bug must be filed in Bugzilla under your > localization's component and assigned to Asa. Set the > 'certification-l10n' flag on the bug to signify the locale is ready > to be tested by MoFo QA. Any problems encountered during this phase > will have separate bugs filed assigned to the locale's owner. > Please take care of the major bits of the trademarks [1]. > - Once your build clears QA, the QA team will set the 'release-l10n' > flag to signify to me that the build is ready to be released and I > will go into action to make the files ready for distribution from the > web and FTP site. > > Again, all of the above only applies to locales not yet having an > official Firefox 1.0 build. If you already had a Firefox 1.0 release, > you should continue to work on the trunk. > > At Axel's request, localizations should translate: > > http://www.mozilla-europe.org/en/products/firefox/start/central.txt > http://www.mozilla-europe.org/en/products/firefox/start/get-involved.txt > http://www.mozilla-europe.org/en/products/firefox/start/about.txt > > Send your results (without BOM, UTF-8 encoded) to > startpages@mozilla-europe.org. > > [1] Trademark stuff: > - bookmarks.html needs to stick to the format of the en-US version. > - Links should be localized, if a link cannot be localized, make sure > that the user expects an English site. > - Search engines should be localized. The list should correspond to > the en-US build, taking into account the order of search engines in > the en-US build. If you need clarification, ask Rafael Ebron (rebron > on irc). Both he and Axel will look closely at the google and yahoo > search engine plugins, including their icons. They'll be able to > provide insight into how to proceed. > > Axel and Gandalf helped to lay down a large part of the process for > managing 1.0.1 check-ins. Thanks to them both for their hard work and > to the l10n community for your on-going support of the Mozilla project! Fantastic, thanks to all for your help and the detailed notes on what to do. David
![]() |
0 |
![]() |
Damjan wrote: >>So, for those of you who haven't released a Firefox 1.0, are working on >>a localization for 1.0.1, and haven't been in touch, the l10n community >>needs to hear from you. Please reply to this thread and announce your >>project's plans. There's still enough time for your locale to land, get >>official sign-off, and be a part of the upcoming 1.0.1 release in the >>"first wave." > > > I hope the mk-MK translation will be approved in time for 1.0.1. > I beleive its ready and I have succesfully tested a Linux build. > The translation is currently been reviewed by MoFO here: > https://bugzilla.mozilla.org/show_bug.cgi?id=276345 > but I wonder what's going on, since there's not been any changes in the > recent 7 days. But 276345 is really just about your CVS account. We have nagged about that yesterday. https://bugzilla.mozilla.org/show_bug.cgi?id=281011 is the real blocker right now. Reread Chase's mail, esp the part about the matching bookmarks structure. Your's does not. I should probably start to word that stuff differently, it seems like "crew picks" is only something in my head, and never made it to a broader audience. Basically, "matching the structure of the en-US bookmarks" means, no other folders than those present, and no significant change in the amount of entries in each of those folders. Plus, make sure that users expect an english site, if that is in bookmarks due to the lack of a localized one. Axel
![]() |
0 |
![]() |
David, I think you don't need to migrate your localisation to an XPI. You just need to submit your localisation according to the directory structure in http://lxr.mozilla.org/aviarybranch/source/toolkit/locales/en-US/ and http://lxr.mozilla.org/aviarybranch/source/browser/locales/en-US/ for your initial check-in. The Mozilla nightly builds will provide you with all XPIs and types of build under the ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0-l10n/ for you to QA. Have a look at Bugzilla 270208 as a reference. Dewi. Ysgrifennodd David Fraser: > Chase Phillips wrote: > >> So, for those of you who haven't released a Firefox 1.0, are working >> on a localization for 1.0.1, and haven't been in touch, the l10n >> community needs to hear from you. Please reply to this thread and >> announce your project's plans. There's still enough time for your >> locale to land, get official sign-off, and be a part of the upcoming >> 1.0.1 release in the "first wave." > > > We have a completed Xhosa build that we would like to include in 1.0.1 > (as I mentioned on IRC). I will check on the status of other South > African languages and reply again if there are any more. > > The main delay here is migrating our xpi - we haven't been using Mozilla > Translator, haven't done 0.9 and the auto-migration tool didn't like our > xpi, so I need to find the details of where to move the files etc. > >> The main steps needed to get official release status for 1.0.1 are: >> >> - Initial check-in of a localization, reviewed by Gandalf. >> - QA of the resulting builds by the localization team, fixes requiring >> approval by Gandalf or Axel to land in CVS. ** Do not check-in >> without approval! ** Again, please use the approval-l10n flag in >> Bugzilla. >> - Trademark sign-off, QA, and release by Mozilla Foundation engineers. >> To get sign off, a new bug must be filed in Bugzilla under your >> localization's component and assigned to Asa. Set the >> 'certification-l10n' flag on the bug to signify the locale is ready >> to be tested by MoFo QA. Any problems encountered during this phase >> will have separate bugs filed assigned to the locale's owner. >> Please take care of the major bits of the trademarks [1]. >> - Once your build clears QA, the QA team will set the 'release-l10n' >> flag to signify to me that the build is ready to be released and I >> will go into action to make the files ready for distribution from the >> web and FTP site. >> >> Again, all of the above only applies to locales not yet having an >> official Firefox 1.0 build. If you already had a Firefox 1.0 release, >> you should continue to work on the trunk. >> >> At Axel's request, localizations should translate: >> >> http://www.mozilla-europe.org/en/products/firefox/start/central.txt >> http://www.mozilla-europe.org/en/products/firefox/start/get-involved.txt >> http://www.mozilla-europe.org/en/products/firefox/start/about.txt >> >> Send your results (without BOM, UTF-8 encoded) to >> startpages@mozilla-europe.org. >> >> [1] Trademark stuff: >> - bookmarks.html needs to stick to the format of the en-US version. >> - Links should be localized, if a link cannot be localized, make sure >> that the user expects an English site. >> - Search engines should be localized. The list should correspond to >> the en-US build, taking into account the order of search engines in >> the en-US build. If you need clarification, ask Rafael Ebron (rebron >> on irc). Both he and Axel will look closely at the google and yahoo >> search engine plugins, including their icons. They'll be able to >> provide insight into how to proceed. >> >> Axel and Gandalf helped to lay down a large part of the process for >> managing 1.0.1 check-ins. Thanks to them both for their hard work and >> to the l10n community for your on-going support of the Mozilla project! > > > Fantastic, thanks to all for your help and the detailed notes on what to > do. > > David
![]() |
0 |
![]() |
Dewi Jones wrote: > Hello! > > Thanks for the heads up and the instructions. > > We in the Welsh (cy-GB) team are QA'ing the latest builds at the moment > and are confident that we'll make it for 1.0.1 > > One question in the meantime concerning bookmarks.html. > > Can we completely localise the default news RSS feed? We have translated > the title for the entry in bookmarks.html but not the actual link itself. > > I don't know how the fxfeeds.mozilla.org redirection works for other > languages. But at the moment, in the Welsh Firefox you get the English > BBC Worldwide news. > > The BBC however does have a Welsh language news feed > http://news.bbc.co.uk/rss/welsh/newyddion/rss091.xml > > which we would naturally like to have in place instead of English. > > Apologies if this is a silly question and something we should have been > doing anyway. Not silly question. Please do use it. You're one of the lucky guys who actually have a good feed. For all others, we would prefer this to be a news feed of interest to a general non-geek audience. This bookmarks is supposed to be sexy for your mom and pop, not so much for your coding buddies. If your major news outlet has a feed, that'd be cool. Axel
![]() |
0 |
![]() |
David Fraser wrote: > Chase Phillips wrote: > >> So, for those of you who haven't released a Firefox 1.0, are working >> on a localization for 1.0.1, and haven't been in touch, the l10n >> community needs to hear from you. Please reply to this thread and >> announce your project's plans. There's still enough time for your >> locale to land, get official sign-off, and be a part of the upcoming >> 1.0.1 release in the "first wave." > > > We have a completed Xhosa build that we would like to include in 1.0.1 > (as I mentioned on IRC). I will check on the status of other South > African languages and reply again if there are any more. > > The main delay here is migrating our xpi - we haven't been using Mozilla > Translator, haven't done 0.9 and the auto-migration tool didn't like our > xpi, so I need to find the details of where to move the files etc. Either pull a complete source tree, with another locale as example. This is explained on http://www.mozilla.org/projects/firefox/l10n/. If you don't set LOCALES_CVSROOT, then you'll do an anonymous check out. That's going to be your best bet for now. mk_add_options MOZ_CO_LOCALES="de-DE" mk_add_options LOCALES_CO_TAG=AVIARY_1_0_20040515_BRANCH in .mozconfig checks out the german localisation allright. Or, you could just do it the straight away way. cvs -z3 -d:pserver:anonymous@cvs-mirror.mozilla.org:/l10n co mozilla/browser/locales/de-DE mozilla/toolkit/locales/de-DE That scheme spares you to think about wether you want to use the client.mk from 1.0 or 1.0.1. >> The main steps needed to get official release status for 1.0.1 are: >> >> - Initial check-in of a localization, reviewed by Gandalf. >> - QA of the resulting builds by the localization team, fixes requiring >> approval by Gandalf or Axel to land in CVS. ** Do not check-in >> without approval! ** Again, please use the approval-l10n flag in >> Bugzilla. >> - Trademark sign-off, QA, and release by Mozilla Foundation engineers. >> To get sign off, a new bug must be filed in Bugzilla under your >> localization's component and assigned to Asa. Set the >> 'certification-l10n' flag on the bug to signify the locale is ready >> to be tested by MoFo QA. Any problems encountered during this phase >> will have separate bugs filed assigned to the locale's owner. >> Please take care of the major bits of the trademarks [1]. >> - Once your build clears QA, the QA team will set the 'release-l10n' >> flag to signify to me that the build is ready to be released and I >> will go into action to make the files ready for distribution from the >> web and FTP site. >> >> Again, all of the above only applies to locales not yet having an >> official Firefox 1.0 build. If you already had a Firefox 1.0 release, >> you should continue to work on the trunk. >> >> At Axel's request, localizations should translate: >> >> http://www.mozilla-europe.org/en/products/firefox/start/central.txt >> http://www.mozilla-europe.org/en/products/firefox/start/get-involved.txt >> http://www.mozilla-europe.org/en/products/firefox/start/about.txt >> >> Send your results (without BOM, UTF-8 encoded) to >> startpages@mozilla-europe.org. >> >> [1] Trademark stuff: >> - bookmarks.html needs to stick to the format of the en-US version. >> - Links should be localized, if a link cannot be localized, make sure >> that the user expects an English site. >> - Search engines should be localized. The list should correspond to >> the en-US build, taking into account the order of search engines in >> the en-US build. If you need clarification, ask Rafael Ebron (rebron >> on irc). Both he and Axel will look closely at the google and yahoo >> search engine plugins, including their icons. They'll be able to >> provide insight into how to proceed. >> >> Axel and Gandalf helped to lay down a large part of the process for >> managing 1.0.1 check-ins. Thanks to them both for their hard work and >> to the l10n community for your on-going support of the Mozilla project! > > > Fantastic, thanks to all for your help and the detailed notes on what to > do. You're welcome, even more details on top. Axel
![]() |
0 |
![]() |
Ricardo Palomares Martinez wrote: > Zbigniew Braniecki escribi=F3: >=20 >>Basicly, if your language was not released for 1.0, you're free to make= >>any improvements. >=20 > And what about if the language was indeed released but minor changes > were detected and fixed later in community releases, like it has been > the case with es-ES? Is there any chance that FF 1.0.1 locales can > benefit of feedback from 1.0 users? Builds that were released with 1.0 will not be able to update their=20 strings for 1.0.1. This is in order to reduce the workload and review-queues on the=20 engineers and testers. Or, at least, that's what I've been told - and I fully understand;=20 they've got lots of other important work to do. Lets put it this way: If 1 team gets a chance to update their strings,=20 every team will want to do the same, so the "but only us"-argument won't = stand. --=20 Vidar Braut Haarr http://www.firefox.no/
![]() |
0 |
![]() |
Ricardo Palomares Martinez wrote: > Zbigniew Braniecki escribió: > >>Basicly, if your language was not released for 1.0, you're free to make >>any improvements. > > > > And what about if the language was indeed released but minor changes > were detected and fixed later in community releases, like it has been > the case with es-ES? Is there any chance that FF 1.0.1 locales can > benefit of feedback from 1.0 users? 1.0.1 is a top-crasher-low-risk and security fix release. The release that is going to have the polish stuff is 1.1. If a localization has security issues like an unreadable security-related dialog, then we'll ponder to take that for 1.0.1. Polish is going on 1.1, though. This is a compromise, of course. We are approaching 35 locales, and the administrative effort of QA and l10n-owner-sign-off doesn't really mix with the concept of a security update. There is of course still the chance to do community releases. You could start on the somewhat-moving target of 1.1, too, though we have no tinderboxens up there, yet. Which is keeping us from pushing that tree. Once we have that, folks could use localized nightlies with all your latest fixes :-) (Chase has machines coming up for 1.1, so it's looking good for this.) Axel
![]() |
0 |
![]() |
> https://bugzilla.mozilla.org/show_bug.cgi?id=281011 is the real blocker > right now. Reread Chase's mail, esp the part about the matching > bookmarks structure. Your's does not. > > I should probably start to word that stuff differently, it seems like > "crew picks" is only something in my head, and never made it to a > broader audience. > > Basically, "matching the structure of the en-US bookmarks" means, no > other folders than those present, I've added just one folder as explained in bugzilla. I've seen that the si_SL firefox has done that so I assumed it was alright. If it's not alright then I'll just revert to the original bookmarks.html - although I don't see what the problem is. > and no significant change in the amount of entries in each of those > folders. except that the bookmark entries are translated there are no other changes. > Plus, make sure that users expect an english site, if that is in > bookmarks due to the lack of a localized one. How do you mean I do this? -- damjan
![]() |
0 |
![]() |
Damjan wrote: >>https://bugzilla.mozilla.org/show_bug.cgi?id=281011 is the real blocker >>right now. Reread Chase's mail, esp the part about the matching >>bookmarks structure. Your's does not. >> >>I should probably start to word that stuff differently, it seems like >>"crew picks" is only something in my head, and never made it to a >>broader audience. >> >>Basically, "matching the structure of the en-US bookmarks" means, no >>other folders than those present, > > > I've added just one folder as explained in bugzilla. I've seen that the > si_SL firefox has done that so I assumed it was alright. > > If it's not alright then I'll just revert to the original bookmarks.html - > although I don't see what the problem is. I can't really say why si-SL has that. It shouldn't. The problem with those links is that anything in there may be good or ok or politically correct for some, and a total offense for others. That's why we don't want those in. Plain en-US framework, please. >>and no significant change in the amount of entries in each of those >>folders. > > > except that the bookmark entries are translated there are no other changes. > > >>Plus, make sure that users expect an english site, if that is in >>bookmarks due to the lack of a localized one. > > > How do you mean I do this? > If you translate "Mozilla Store" to something in your language, or even something like "Firefox Support Forums", and users end up on an english site that they don't understand, they have a bad user experience. That is why I favour that, if you want to translate those descriptions, they should have be something like "Mozillsky storesky (englishsky)", you get the idea. I personally favour the idea to localize the sites, instead of the descriptions. That is, if you don't have a site in your native language, leave the english title. Just like it would appear if you added the bookmark yourself. But that is more my personal policy, nothing official. I guess, we should discuss that in more detail for 1.1. Axel
![]() |
0 |
![]() |
>>>Basically, "matching the structure of the en-US bookmarks" means, no >>>other folders than those present, >> >> I've added just one folder as explained in bugzilla. I've seen that the >> si_SL firefox has done that so I assumed it was alright. >> >> If it's not alright then I'll just revert to the original bookmarks.html >> - although I don't see what the problem is. > > I can't really say why si-SL has that. It shouldn't. Ahh, can you tell me which one is a legitimate bookmarks file so I'll make ours according to it. > The problem with those links is that anything in there may be good or ok > or politically correct for some, and a total offense for others. That's > why we don't want those in. Well, I could've translated any Mozilla string with something offensive if I wanted to do that, no? > If you translate "Mozilla Store" to something in your language, or even > something like "Firefox Support Forums", and users end up on an english > site that they don't understand, they have a bad user experience. Well, the experience of 99.99% of macedonian computer users is that they have never seen an application in macedonian language. > That is why I favour that, if you want to translate those descriptions, > they should have be something like "Mozillsky storesky (englishsky)", you > get the idea. ok. I'll do like you say. ps. I see that MoFo likes to protect itself (its image) by having somewhat strict rules about the localizations (I mean we contribute 8000 translated strings but can't add some custom bookmarks, pheew). BUT you should know than, in macedonia at least, there would be very little firefox users if it's not for our efforts to distribute and educate people about free software. If we make a stupid Firefox we'll loose the credibillity to ever appear in our community. If we don't care about Firefox most people will just use Internet Explorer. pps. Is this still correct? http://www.mozilla.org/foundation/trademarks/l10n-policy.html 3. The default bookmarks and personal toolbar items should use the same folder structure as the default bookmarks and personal toolbar of the en-US version. The contents of each folder may be modified. The folder title for the "recommended links" folder ("Firefox Crew Picks" for the en-US edition) should be modified to reflect the new authorship (eg "Mozilla Germany Recommends" or similar, chosen by the L10n team). -- damjan
![]() |
0 |
![]() |
Damjan wrote: >>>>Basically, "matching the structure of the en-US bookmarks" means, no >>>>other folders than those present, >>> >>>I've added just one folder as explained in bugzilla. I've seen that the >>>si_SL firefox has done that so I assumed it was alright. >>> >>>If it's not alright then I'll just revert to the original bookmarks.html >>>- although I don't see what the problem is. >> >>I can't really say why si-SL has that. It shouldn't. > > > Ahh, can you tell me which one is a legitimate bookmarks file so I'll make > ours according to it. The one and only legitimate one is the en-US one. >>The problem with those links is that anything in there may be good or ok >>or politically correct for some, and a total offense for others. That's >>why we don't want those in. > > > Well, I could've translated any Mozilla string with something offensive if > I wanted to do that, no? Yes, but most strings are generally either offensive to all or to nobody. A "good website" is way different. >>If you translate "Mozilla Store" to something in your language, or even >>something like "Firefox Support Forums", and users end up on an english >>site that they don't understand, they have a bad user experience. > > > Well, the experience of 99.99% of macedonian computer users is that they > have never seen an application in macedonian language. > > >>That is why I favour that, if you want to translate those descriptions, >>they should have be something like "Mozillsky storesky (englishsky)", you >>get the idea. > > > ok. I'll do like you say. > > > > ps. > I see that MoFo likes to protect itself (its image) by having somewhat > strict rules about the localizations (I mean we contribute 8000 translated > strings but can't add some custom bookmarks, pheew). > BUT you should know than, in macedonia at least, there would be very little > firefox users if it's not for our efforts to distribute and educate people > about free software. > If we make a stupid Firefox we'll loose the credibillity to ever appear in > our community. If we don't care about Firefox most people will just use > Internet Explorer. You're not supposed to do a stupid Firefox. But you're not supposed to make a Firefox that claims to be more clever than the en-US one, either. And we learned the hard way that "good sites" are not clever. > pps. > Is this still correct? > http://www.mozilla.org/foundation/trademarks/l10n-policy.html > > 3. The default bookmarks and personal toolbar items should use the same > folder structure as the default bookmarks and personal toolbar of the en-US > version. The contents of each folder may be modified. The folder title for > the "recommended links" folder ("Firefox Crew Picks" for the en-US edition) > should be modified to reflect the new authorship (eg "Mozilla Germany > Recommends" or similar, chosen by the L10n team). No, the section about the crew picks is a left over from our hard lectures. I filed a bug to get it removed. Sorry, you're the first one to catch that. Axel
![]() |
0 |
![]() |
Chase Phillips wrote: > Again, all of the above only applies to locales not yet having an > official Firefox 1.0 build. If you already had a Firefox 1.0 release, > you should continue to work on the trunk. ga-IE is requesting a review of a couple of patches in bug 278428. These will pave the way for 1.0.1 candidate release builds. -- Brian King www.mozdev.org - free project hosting for the Mozilla community
![]() |
0 |
![]() |
Axel Hecht escribió: > Ricardo Palomares Martinez wrote: > >> Zbigniew Braniecki escribió: >> >>> Basicly, if your language was not released for 1.0, you're free to make >>> any improvements. >> >> >> >> >> And what about if the language was indeed released but minor changes >> were detected and fixed later in community releases, like it has been >> the case with es-ES? Is there any chance that FF 1.0.1 locales can >> benefit of feedback from 1.0 users? > > > > 1.0.1 is a top-crasher-low-risk and security fix release. > The release that is going to have the polish stuff is 1.1. > > If a localization has security issues like an unreadable > security-related dialog, then we'll ponder to take that for 1.0.1. > Polish is going on 1.1, though. > > This is a compromise, of course. We are approaching 35 locales, and the > administrative effort of QA and l10n-owner-sign-off doesn't really mix > with the concept of a security update. > > There is of course still the chance to do community releases. You could > start on the somewhat-moving target of 1.1, too, though we have no > tinderboxens up there, yet. Which is keeping us from pushing that tree. > Once we have that, folks could use localized nightlies with all your > latest fixes :-) (Chase has machines coming up for 1.1, so it's looking > good for this.) > > Axel Isn't this a good chance to solve https://bugzilla.mozilla.org/show_bug.cgi?id=271470 by changing one line in one file? This affects lots of locales. Maybe our https://bugzilla.mozilla.org/show_bug.cgi?id=271782 may be solved too. That kind of changes do not require too much effort for QA.
![]() |
0 |
![]() |
Dewi Jones wrote: > David, > > I think you don't need to migrate your localisation to an XPI. You just > need to submit your localisation according to the directory structure in I meant from the XPI structure, but thanks for the pointers > > http://lxr.mozilla.org/aviarybranch/source/toolkit/locales/en-US/ > and > http://lxr.mozilla.org/aviarybranch/source/browser/locales/en-US/ > > for your initial check-in. > > The Mozilla nightly builds will provide you with all XPIs and types of > build under the > ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0-l10n/ > for you to QA. > > Have a look at Bugzilla 270208 as a reference. Thanks Dewi, I used your submitted source zip as an example David
![]() |
0 |
![]() |
David Fraser wrote: > Chase Phillips wrote: > >> So, for those of you who haven't released a Firefox 1.0, are working >> on a localization for 1.0.1, and haven't been in touch, the l10n >> community needs to hear from you. Please reply to this thread and >> announce your project's plans. There's still enough time for your >> locale to land, get official sign-off, and be a part of the upcoming >> 1.0.1 release in the "first wave." > > > We have a completed Xhosa build that we would like to include in 1.0.1 > (as I mentioned on IRC). I will check on the status of other South > African languages and reply again if there are any more. I have now submitted a Xhosa source set on the relevant bug. We have also got Afrikaans ready David
![]() |
0 |
![]() |
Marcelo Poli wrote: <...> > > Isn't this a good chance to solve > https://bugzilla.mozilla.org/show_bug.cgi?id=271470 > by changing one line in one file? This affects lots of locales. > Maybe our https://bugzilla.mozilla.org/show_bug.cgi?id=271782 may be > solved too. > That kind of changes do not require too much effort for QA. Well, bug 271470 could expose locale strings that haven't been exposed before. If somebody does a in-depth analysis of what happens with true, false, some_translation in terms of UI and localized-string-exposure, I could give a much better word. Bug 271782 would get an a- from me. It's a sorry bug, but not serious enough to get it into 1.0.1. Axel
![]() |
0 |
![]() |
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC36D267D581ACB583648248B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Axel Hecht kirjoitti: > Marcelo Poli wrote: > <...> > >> >> Isn't this a good chance to solve >> https://bugzilla.mozilla.org/show_bug.cgi?id=271470 >> by changing one line in one file? This affects lots of locales. >> Maybe our https://bugzilla.mozilla.org/show_bug.cgi?id=271782 may be >> solved too. >> That kind of changes do not require too much effort for QA. > > > Well, bug 271470 could expose locale strings that haven't been exposed > before. > If somebody does a in-depth analysis of what happens with true, false, > some_translation in terms of UI and localized-string-exposure, I could > give a much better word. I read this as saying that if the l10n teams affected can verify their builds ASAP to work OK after the change from extend=<incorrect> to extend=true, then fixing the bug might be possible. Is this correct? fi-FI is verified by the l10n team (and by comment #2) to work fixed. I suggest the other affected locale teams verify their own build with extend=true ASAP. The remaining affected locales: ca-AD, cs-CZ, da-DK, es-AR, es-ES, ga-IE, ko-KR, sk-SK, sq-AL, zh-CN -- yhteystiedot, contact info: www.dabase.com/~ville/ --------------enigC36D267D581ACB583648248B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCDd4jgHfjgq8xQXkRArVHAKCYTHmowt/yRvkXTS2As87t2lxtVACbBT7M 2mIIAXjMF9yo1ZWwTxdDGpw= =aT03 -----END PGP SIGNATURE----- --------------enigC36D267D581ACB583648248B--
![]() |
0 |
![]() |
> The one and only legitimate one is the en-US one. Just to confirm all this. Please correct me if something is wrong, and fill in the blanks. First none of these bookmarks should be removed and folder name should be translated. And no additional folders can be added! Then: http://www.mozilla.org/products/firefox/central.html should link to a localized version of http://www.mozilla-europe.org/en/products/firefox/start/central.txt http://fxfeeds.mozilla.org/ about:livemark-loading Should lead to news.bbc.co.uk if the feed is available in the language. (But if not, can the link lead to the state/national television or other news service from the country/language zone?) http://www.google.com/search?q=%s http://dictionary.reference.com/search?q=%s http://www.google.com/search?q=stocks:%s http://en.wikipedia.org/wiki/Special:Search?search=%s http://www.urbandictionary.com/define.php?term=%s All these should be localized and they should link to language specific pages. For example http://en.wikipedia.org/wiki/Special:Search?search=%s could link to http://de.wikipedia.org/wiki/Special:Search?search=%s for German. If there isn't a localized version of the page, the link should point to the English one and it should be clear that it points to an English page: for example 'Wikipedia Quicksearch [en]' http://start.mozilla.org/firefox/ I don't know where this should link... now it redirects to http://www.google.com/firefox/ and gives back 404. http://www.mozilla.org/products/firefox/central.html should also link to a localized version of http://www.mozilla-europe.org/en/products/firefox/start/central.txt http://update.mozilla.org/?application=firefox Shouldn't be changed (or are there update pages in different languages?). http://getfirefox.com/ http://www.mozilla.org/ http://www.mozillazine.org/ http://www.mozillastore.com/ http://www.spreadfirefox.com/ For all these rules about Quick Searches apply. Right? And finally, can the localizing team add a link to their web site? If they can, in which folder should this link go? -- Novica
![]() |
0 |
![]() |
Ville Pohjanheimo wrote: > Axel Hecht kirjoitti: > >> Marcelo Poli wrote: >> <...> >> >>> >>> Isn't this a good chance to solve >>> https://bugzilla.mozilla.org/show_bug.cgi?id=271470 >>> by changing one line in one file? This affects lots of locales. >>> Maybe our https://bugzilla.mozilla.org/show_bug.cgi?id=271782 may be >>> solved too. >>> That kind of changes do not require too much effort for QA. >> >> >> >> Well, bug 271470 could expose locale strings that haven't been exposed >> before. >> If somebody does a in-depth analysis of what happens with true, false, >> some_translation in terms of UI and localized-string-exposure, I could >> give a much better word. > > > I read this as saying that if the l10n teams affected can verify their > builds ASAP to work OK after the change from extend=<incorrect> to > extend=true, then fixing the bug might be possible. Is this correct? > > fi-FI is verified by the l10n team (and by comment #2) to work fixed. > > I suggest the other affected locale teams verify their own build with > extend=true ASAP. The remaining affected locales: ca-AD, cs-CZ, da-DK, > es-AR, es-ES, ga-IE, ko-KR, sk-SK, sq-AL, zh-CN Not really. My personal (!) opinion here is that this slipped l10n QA once, and I'd like to get a code analysis of the difference in UI the three choices make. A simple "worksforme" is not enough to make me approve this for 1.0.1, I would need a risk analysis on source basis. As I seem to know best which analysis I want, I just did it. https://bugzilla.mozilla.org/show_bug.cgi?id=271470#c17 Axel
![]() |
0 |
![]() |
Novica Nakov wrote: > >> The one and only legitimate one is the en-US one. > > > Just to confirm all this. Please correct me if something is wrong, and > fill in the blanks. > > First none of these bookmarks should be removed and folder name should > be translated. And no additional folders can be added! Yes. (removal of quicksearches explained below.) > Then: > > http://www.mozilla.org/products/firefox/central.html > should link to a localized version of > http://www.mozilla-europe.org/en/products/firefox/start/central.txt > > > http://fxfeeds.mozilla.org/ > about:livemark-loading > > Should lead to news.bbc.co.uk if the feed is available in the language. > (But if not, can the link lead to the state/national television or other > news service from the country/language zone?) This feed should lead to the major news outlet in your area. There is some personal judgement in this, yes, but there is no explicit bias towards bbc. If the bbc offers a good feed for you, be happy to take it. I never tested if the bbc would offer crappy feeds, though ;-). So, take the description out of the braces, and make that a This link should lead to the state/national television or other news service from the country/language zone. If you have problems finding one, checking with the bbc for localized feeds is one option, or just using the en-US feed as fallback is ok, too. > http://www.google.com/search?q=%s > http://dictionary.reference.com/search?q=%s > http://www.google.com/search?q=stocks:%s > http://en.wikipedia.org/wiki/Special:Search?search=%s > http://www.urbandictionary.com/define.php?term=%s > > All these should be localized and they should link to language specific > pages. > For example http://en.wikipedia.org/wiki/Special:Search?search=%s could > link to > http://de.wikipedia.org/wiki/Special:Search?search=%s > for German. If there isn't a localized version of the page, the link > should point to the English one and it should be clear that it points to > an English page: for example 'Wikipedia Quicksearch [en]' dictionary.com and urbandictionary.com don't make an awful lot of sense in most locales, feel free to replace them with webservices of your own language, if they exist. If they do not exist, keep the english ones. > http://start.mozilla.org/firefox/ > > I don't know where this should link... now it redirects to > http://www.google.com/firefox/ > and gives back 404. Woof, woof, bad dog google. Make that http://start.mozilla.org/firefox (without the trailing '/'). Some machines of google still don't understand that redirect. > http://www.mozilla.org/products/firefox/central.html > should also link to a localized version of > http://www.mozilla-europe.org/en/products/firefox/start/central.txt Yes. > http://update.mozilla.org/?application=firefox > > Shouldn't be changed (or are there update pages in different languages?). Sadly, not. Bad webapp. > http://getfirefox.com/ > http://www.mozilla.org/ > http://www.mozillazine.org/ > http://www.mozillastore.com/ > http://www.spreadfirefox.com/ > For all these rules about Quick Searches apply. Right? If you have a mozilla.org affiliate website for your language, it should be added. There is no localization for sfx or the store as of now. You can add firefox forums in your language here, for example, or localized support pages. Not 20, but 2-3 added links for your locale is ok. > And finally, can the localizing team add a link to their web site? If > they can, in which folder should this link go? The credits for your team should go into the paragraph on http://www.mozilla-europe.org/en/products/firefox/start/about.txt. We should really have made better docs for this, I wonder if someone cares to wiki this up? Axel
![]() |
0 |
![]() |
Marcelo Poli <mpoli.ELIMINATETHIS@lt24.zzn.com> wrote in message news:<cujhfa$r9b20@ripley.netscape.com>... > Isn't this a good chance to solve > https://bugzilla.mozilla.org/show_bug.cgi?id=271470 > by changing one line in one file? This affects lots of locales. Yes. This might be an idea if someone provide low risk patch. > Maybe our https://bugzilla.mozilla.org/show_bug.cgi?id=271782 may be > solved too. > That kind of changes do not require too much effort for QA. Did you read this thread? If we will approve such checkin next teams will demand to check in their low-risks patches because there's no reason to give a special plus to one team, right? So the answer is no. There will be no changes to already released localizations. That was a decision of Mozilla Foundation for Firefox 1.0.1. There is exception for issues that touches security or huge usability problems. If anyone of you has such patch, talk to Axel and he will decide, but for sure it's not something for "bad accesskey" issue. Greetings Zbigniew Braniecki -- AviaryPL
![]() |
0 |
![]() |
> We should really have made better docs for this, I wonder if someone > cares to wiki this up? I added what you were talking about to http://wiki.mozilla.org/wiki/L10n:Firefox_Extras Feel free to improve/correct that page ;-) Robert Kaiser
![]() |
0 |
![]() |
Le 12/02/2005 13:54, Axel Hecht a ecrit : > dictionary.com and urbandictionary.com don't make an awful lot of sense > in most locales, feel free to replace them with webservices of your own > language, if they exist. If they do not exist, keep the english ones. For the fr-FR build, FF1.0 used the voila.com online dictionnary, unfortunately theey closed their service last month and we have now a non-fonctional searchplugin in the French build. Will Frenchmozilla be allowed to change this link for 1.0.1? AFAIK there is no FR alternative so they would probably revert to en English dictionnary. Pascal
![]() |
0 |
![]() |
pascal chevrel wrote: > > > Le 12/02/2005 13:54, Axel Hecht a ecrit : > >> dictionary.com and urbandictionary.com don't make an awful lot of >> sense in most locales, feel free to replace them with webservices of >> your own language, if they exist. If they do not exist, keep the >> english ones. > > > For the fr-FR build, FF1.0 used the voila.com online dictionnary, > unfortunately theey closed their service last month and we have now a > non-fonctional searchplugin in the French build. Will Frenchmozilla be > allowed to change this link for 1.0.1? AFAIK there is no FR alternative > so they would probably revert to en English dictionnary. Please file a bug and provide a patch. Request l10n-approval and I'll talk it through with mofo QA. Axel
![]() |
0 |
![]() |
Novica Nakov wrote: > http://start.mozilla.org/firefox/ > > I don't know where this should link... now it redirects to > http://www.google.com/firefox/ > and gives back 404. See bug 268603 (and yes, as previously mentioned remove the trailing slash and it works fine). Supposedly Google's /kinda/ working on this. Jeff Walden -- Want a free Mini Mac? http://www.freeminimacs.com/?r=14069930 Rediscover the Web! http://snurl.com/get_firefox
![]() |
0 |
![]() |
Le 12/02/2005 16:25, Axel Hecht a ecrit : > pascal chevrel wrote: > >> >> >> Le 12/02/2005 13:54, Axel Hecht a ecrit : >> >>> dictionary.com and urbandictionary.com don't make an awful lot of >>> sense in most locales, feel free to replace them with webservices of >>> your own language, if they exist. If they do not exist, keep the >>> english ones. >> >> >> >> For the fr-FR build, FF1.0 used the voila.com online dictionnary, >> unfortunately theey closed their service last month and we have now a >> non-fonctional searchplugin in the French build. Will Frenchmozilla be >> allowed to change this link for 1.0.1? AFAIK there is no FR >> alternative so they would probably revert to en English dictionnary. > > > Please file a bug and provide a patch. Request l10n-approval and I'll > talk it through with mofo QA. > > Axel https://bugzilla.mozilla.org/show_bug.cgi?id=282041 I send a message to the localiser to ask him to file a patch. Pascal
![]() |
0 |
![]() |
I've just created an issue (282078) in Bugzilla for patches (with approval-l10n flag) for the upcoming Welsh (cy-GB) Firefox localisation. Looking forward to the next stages however, Chase says : >- Trademark sign-off, QA, and release by Mozilla Foundation engineers. > To get sign off, a new bug must be filed in Bugzilla under your > localization's component and assigned to Asa. Set the > 'certification-l10n' flag on the bug to signify the locale is ready > to be tested by MoFo QA. Welsh doesn't have a 'Component' in Bugzilla. I've used 'Other' for 282078. How would it be best to resolve this? I think some other upcoming languages don't have a 'Component' in Bugzilla either. Should we all say 'Other' with our 'certification-l10n' flags? Cheers, Hwyl, Dewi. Ysgrifennodd Chase Phillips: > As a heads up to all l10n contributors who were a part of the Firefox > 1.0 release and those who are working to be a part of our 1.0.1 release, > we'll be transitioning our l10n build systems so they generate 1.0.1 > builds this weekend. This will conclude our automated builds of Firefox > 1.0. When the transition is complete, new nightly builds will begin > appearing in: > > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1-l10n/ > > > If your localization has a released Firefox 1.0, you should not need to > make any changes for the 1.0.1 release. At this time, no UI string > changes are planned -- and we want to avoid making any! :) Since you'll > basically get a Firefox 1.0.1 "for free," please proceed to work in CVS > on the trunk where localization work on the next major Firefox release > is making good progress. > > If your localization has not yet released Firefox 1.0, you will continue > to commit changes on the Aviary 1.0 branch though you will need to shift > your attention away from Firefox 1.0 to Firefox 1.0.1. As a reminder, > this branch tag is: > > AVIARY_1_0_20040515_BRANCH > > Gandalf and Axel have been given the power to grant l10n approvals for > this drive to Firefox 1.0.1. Where there's any question about whether > a change should land, Asa and myself will help out. A new Bugzilla flag > 'approval-l10n' has been added so that l10n-specific patches can be > brought to Gandalf's and Axel's attention as candidates for landing. > They will reuse this flag as the need arises. > > So, for those of you who haven't released a Firefox 1.0, are working on > a localization for 1.0.1, and haven't been in touch, the l10n community > needs to hear from you. Please reply to this thread and announce your > project's plans. There's still enough time for your locale to land, get > official sign-off, and be a part of the upcoming 1.0.1 release in the > "first wave." > > The main steps needed to get official release status for 1.0.1 are: > > - Initial check-in of a localization, reviewed by Gandalf. > - QA of the resulting builds by the localization team, fixes requiring > approval by Gandalf or Axel to land in CVS. ** Do not check-in > without approval! ** Again, please use the approval-l10n flag in > Bugzilla. > - Trademark sign-off, QA, and release by Mozilla Foundation engineers. > To get sign off, a new bug must be filed in Bugzilla under your > localization's component and assigned to Asa. Set the > 'certification-l10n' flag on the bug to signify the locale is ready > to be tested by MoFo QA. Any problems encountered during this phase > will have separate bugs filed assigned to the locale's owner. > Please take care of the major bits of the trademarks [1]. > - Once your build clears QA, the QA team will set the 'release-l10n' > flag to signify to me that the build is ready to be released and I > will go into action to make the files ready for distribution from the > web and FTP site. > > Again, all of the above only applies to locales not yet having an > official Firefox 1.0 build. If you already had a Firefox 1.0 release, > you should continue to work on the trunk. > > At Axel's request, localizations should translate: > > http://www.mozilla-europe.org/en/products/firefox/start/central.txt > http://www.mozilla-europe.org/en/products/firefox/start/get-involved.txt > http://www.mozilla-europe.org/en/products/firefox/start/about.txt > > Send your results (without BOM, UTF-8 encoded) to > startpages@mozilla-europe.org. > > [1] Trademark stuff: > - bookmarks.html needs to stick to the format of the en-US version. > - Links should be localized, if a link cannot be localized, make sure > that the user expects an English site. > - Search engines should be localized. The list should correspond to > the en-US build, taking into account the order of search engines in > the en-US build. If you need clarification, ask Rafael Ebron (rebron > on irc). Both he and Axel will look closely at the google and yahoo > search engine plugins, including their icons. They'll be able to > provide insight into how to proceed. > > Axel and Gandalf helped to lay down a large part of the process for > managing 1.0.1 check-ins. Thanks to them both for their hard work and > to the l10n community for your on-going support of the Mozilla project! > > Chase
![]() |
0 |
![]() |
Dewi Jones wrote: > I've just created an issue (282078) in Bugzilla for patches (with > approval-l10n flag) for the upcoming Welsh (cy-GB) Firefox localisation. > > Looking forward to the next stages however, Chase says : > > >- Trademark sign-off, QA, and release by Mozilla Foundation engineers. > > To get sign off, a new bug must be filed in Bugzilla under your > > localization's component and assigned to Asa. Set the > > 'certification-l10n' flag on the bug to signify the locale is ready > > to be tested by MoFo QA. > Welsh doesn't have a 'Component' in Bugzilla. I've used 'Other' for > 282078. How would it be best to resolve this? I think some other > upcoming languages don't have a 'Component' in Bugzilla either. Should > we all say 'Other' with our 'certification-l10n' flags? Use Others for your bugs until you have your own component. I wonder if there is any policy within mlp-staff for this, but I'd suggest that you file a bug to get your component created. Axel <...>
![]() |
0 |
![]() |
Chase Phillips wrote: <...> > If your localization has a released Firefox 1.0, you should not need to > make any changes for the 1.0.1 release. At this time, no UI string > changes are planned -- and we want to avoid making any! :) Since you'll > basically get a Firefox 1.0.1 "for free," please proceed to work in CVS > on the trunk where localization work on the next major Firefox release > is making good progress. > > If your localization has not yet released Firefox 1.0, you will continue > to commit changes on the Aviary 1.0 branch though you will need to shift > your attention away from Firefox 1.0 to Firefox 1.0.1. As a reminder, > this branch tag is: > > AVIARY_1_0_20040515_BRANCH <...> Clearing things up a little, if you take a look at the 1.0.1 branch, you will see two check-ins to the en-US directories. One is a security related fix, which adds a new error code. This error code description is a new entry in xslt.properties, which won't be added to the localized builds. That error code is hard coded to english in another part of that patch. The other check-in is to separate the umo services domain names. We're still talking in that bug (https://bugzilla.mozilla.org/show_bug.cgi?id=271473) if we want this change in any l10n. This is supposed to be backwards compatible though (we don't want to hork 1.0 builds, for sure), so it is no blocker. Benjamin and I are watching check-ins like this closely, so no need to worry on your side. Bottom line, there may be check-ins to the en-US directories, but up to now we haven't seen changes that require action on behalf of l10n. Axel
![]() |
0 |
![]() |
> So, for those of you who haven't released a Firefox 1.0, are working on > a localization for 1.0.1, and haven't been in touch, the l10n community > needs to hear from you. Please reply to this thread and announce your > project's plans. There's still enough time for your locale to land, get > official sign-off, and be a part of the upcoming 1.0.1 release in the > "first wave." Just as a note, we have a request for a Vietnamese L10n project at https://bugzilla.mozilla.org/show_bug.cgi?id=282099 (I don't know that how soon they will have some finished work) Robert Kaiser
![]() |
0 |
![]() |
Chase Phillips wrote: > As a heads up to all l10n contributors who were a part of the Firefox > 1.0 release and those who are working to be a part of our 1.0.1 release, > we'll be transitioning our l10n build systems so they generate 1.0.1 > builds this weekend. This will conclude our automated builds of Firefox > 1.0. When the transition is complete, new nightly builds will begin > appearing in: > > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1-l10n/ > This move has happened and a few things fell on the ground. I merged our added locales from the minibranch we had onto the aviary 1.0.1 branch, so the 1.0.1 l10n tinderbox will pick them up. The corresponding l10n tinderboxens for those locales (cy-GB, eu-ES, pa-IN, pt-PT, sk-SK) are waking up and builds for those trees should show up with the next round of update. I also tweaked compare-locales.pl to actually turn up green builds, independent wether you have 27 in xslt.properties or not. This reflects the fact that the code pulling that property doesn't mind either. Which was the rationale to let that patch land into our l10n-really-chilly-days. So, hack away on those 5 locales, give them some thorough QA bits. If you need platform specific testing, be sure to ask loud and cleary, possibly with opening a new thread here. Axel
![]() |
0 |
![]() |
> So, for those of you who haven't released a Firefox 1.0, are working on > a localization for 1.0.1, and haven't been in touch, the l10n community > needs to hear from you. Please reply to this thread and announce your > project's plans. There's still enough time for your locale to land, get > official sign-off, and be a part of the upcoming 1.0.1 release in the > "first wave." I have some questions about the building process: Does this build process include building of official XPIs available at ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0/ ? Is there a difference among the XPIs for Mac, Win and Linux? -- Novica
![]() |
0 |
![]() |
Novica Nakov wrote: > Does this build process include building of official XPIs available at > ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0/ ? Yes. > Is there a difference among the XPIs for Mac, Win and Linux? Unfortunately, I don't know the answer to that question. It may be that one platform's XPIs will work for all platforms. Testing and figuring this out, though, hasn't been a high priority for me compared to the other things I need to get done. Chase
![]() |
0 |
![]() |