Trademarks approval timeline and RC1
Axel Hecht
as has been announced in netscape.public.mozilla.l10n, the product
development team did several changes to the search engine plugins and
the bookmarks for Firefox 1.5.
This renders all previous trademarks approvals obsolete.
In order to accomodate to these changes in a reasonable manner, we're
opening up the trademarks files and are going to run the approval
process from scratch.
The rules for trademarks approval are as follows:
- Search engines:
-- Order must be google 1st, yahoo 2nd. (Exceptions need a bug with
rationale, that bug should block
https://bugzilla.mozilla.org/show_bug.cgi?id=307393)
-- Any two search plugins in our CVS with the same file name or plugin
name (the name attr in the SEARCH tag) need to be
the same plugin, up to the char. Binary equal, not just equivalent. For
locales with different localizations for different regions, make sure to
communicate about your choices.
-- These changes likely include renaming your plugins. There have been
questions about using long locale names instead of short ones in those
URLs and file names, I'm fine with that.
-- The suite of search engine plugins should be useful to the general
public, hopefully of that particular locale.
-- no dictionary.com, no unused files. Learn to use cvs remove.
-- default encoding of search engine plugins is x-mac-roman.
- Bookmarks:
-- Folder structure like en-US (this is not a problem these days, but
for the sake of completeness, I add it).
-- One news feed, of interest to general public, one or the major news
outlet for your region. Larger locales may want to ask for approval to
add the feed, it does cause traffic.
-- Don't confuse your users by more links than necessary, less is more.
Communities should have a single page for new users, something
portal-like. If you have such a page, link to that instead of
mozillazine.org.
There will likely be changes to the web-content related to the Firefox
product like the start page snippets. These changes can be dealt with
post-release, that is, they're not required for the trademarks review of
the code. We do assume a commitment to follow up on these changes in a
timely manner, though.
RC 1 will be done as beta 2 was, that is, it will be pulled by date and
pushed without QA. As we don't have trademarks reviews by then, this is
not really an l10n RC.
We'll kick off trademark reviews on November 2nd, starting November 2nd,
the trademarks relevant files will be locked down again, that is, you
need to file bugs with patches and request approval-l10n to land them.
We'll announce the time line and process for simultanious release with
en-US mid next week, too.
Please put questions into the newsgroup, unless they're really confidential.
Axel
(Sorry if you get that message twice or three times, I got the newsgroup
name wrong.)
Håvard Mork
> -- Any two search plugins in our CVS with the same file name or plugin
> name (the name attr in the SEARCH tag) need to be
> the same plugin, up to the char. Binary equal, not just equivalent. For
> locales with different localizations for different regions, make sure to
> communicate about your choices.
Meaning that if we use www.google.no instead of www.google.com, the
UI-visible name of the plugin must be "Google.no" instead of just "Google"?
Google is not actually a problem, since it redirects nicely. Yahoo, on
the other hand, doesn't consider browser's language when presenting
search results (must modify URL). Thus to accomodate using Yahoo for our
locale, we need to call it "Yahoo.no".
Personally, I'm not happy about this.
Axel Hecht
So say one has a swedish and a norwegian yahoo search plugin installed,
how are they supposed to know which to select from the UI?
"Yahoo (Norway)" is a valid name, too, there is no need to make that a
URL. Actually, yahoo probably likes
"Yahoo! Norway Search"
(Not sure if we need to follow that)
Axel
Axel Hecht
<...>
>
> RC 1 will be done as beta 2 was, that is, it will be pulled by date and
> pushed without QA. As we don't have trademarks reviews by then, this is
> not really an l10n RC.
>
Quoting Chase:
> As of 21:30 tonight, the l10n build trees on cerberus, maya, and karma
> have been reconfigured to build from 1.5rc1 en-US packages. They have
> also been locked to pull-by-date the l10n files themselves per our
> discussion earlier today on IRC. The date used for the l10n files is
> "10/26/2005 19:00:00 PST".
>
> The l10n files will be collected into a candidates directory as a part
> of the release process and will be included in the push of 1.5rc1 files,
> assuming all goes to plan. :)
>
> PS I shut off some building of l10n on the trunk and aviary1.0.1 branches
> for now since we're quite focused on Mozilla1.8. Please let me know if
> this is an immediate inconvenience in your opinion or for people in the
> l10n community.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8-1.5rc1-l10n/
has the l10n RC1 bits, please test them thoroughly. It'd be cool if you
could watch out on the QA blog, too, to see how we can make use of
testrunner, once marcia has it up there.
Chase, rebron and I agreed to pull by date to keep the RC1 out of your
way for trademarks fixing. Locking down the tree until after RC1 would
have been the other way of doing it, which would have put yours and our
timeline for synch release in hazard.
I don't expect any problem with the change to the trunk and aviary
tinderboxens, this is just going to be for a few days.
Axel
Michele Dal Corso
> -- Any two search plugins in our CVS with the same file name or plugin
> name (the name attr in the SEARCH tag) need to be
> the same plugin, up to the char.
I don't think it's a good idea to change SP names: Google localized [1]
isn't Google.it [2]! Google.it search plug-in only search in Italian
sites instead of Google.com localized in Italian that searches in the
Web (worldwide) but with Italian interface.
It exists two search engine plug-ins for Google for Italian (and maybe
for other languages):
* Google (included in Firefox), that it is only a localized version
of the Google SP,
* Google IT SP that searches in the google.it site limited to Italian
sites [3].
Renaming the actual Google plug-in in something like Google.it it add
only confusion between two versions of SP.
The same thing it's related to other default SP: I think that the event
that an Italian user installs a lang-original SP of Google or eBay SP is
very remote, and in this case should the en-US SP called Google [en] or
eBay [en] and not the opposite.
It also breaks the region.properties file:
> browser.search.defaultenginename=Google
> browser.search.order.1=Google
> browser.search.order.2=Yahoo
these properties keys refers to SP name attribute, and make the search
bar context menu looking bad (is not useful for 99% Italian users to see
.it extension to almost all included SP when it is obvious that a
localized version of FX contains localized SP...).
So please don't ask us to rename SPs in Google.it, eBay.it... manner,
but require to us only the difference in the file name. Please leave us
the decision of opportunity to modify the SP name attribute for each locale.
Thanks,
Michele Dal Corso
[1] http://www.google.com/webhp?hl=it
[2] http://www.google.it/
[3] http://mycroft.mozdev.org/plugins/googleIT.src
Axel Hecht
> Axel Hecht ha scritto:
>> -- Any two search plugins in our CVS with the same file name or plugin
>> name (the name attr in the SEARCH tag) need to be
>> the same plugin, up to the char.
>
> I don't think it's a good idea to change SP names: Google localized [1]
> isn't Google.it [2]! Google.it search plug-in only search in Italian
> sites instead of Google.com localized in Italian that searches in the
> Web (worldwide) but with Italian interface.
>
> It exists two search engine plug-ins for Google for Italian (and maybe
> for other languages):
> * Google (included in Firefox), that it is only a localized version
> of the Google SP,
> * Google IT SP that searches in the google.it site limited to Italian
> sites [3].
>
> Renaming the actual Google plug-in in something like Google.it it add
> only confusion between two versions of SP.
How can having them be the same name be non-confusing?
Note that if this is actually a problem to you, you could just use the
google.com plugin, which should redirect to google.it and italian lang
based on the users IP.
> The same thing it's related to other default SP: I think that the event
> that an Italian user installs a lang-original SP of Google or eBay SP is
> very remote, and in this case should the en-US SP called Google [en] or
> eBay [en] and not the opposite.
> It also breaks the region.properties file:
>> browser.search.defaultenginename=Google
>> browser.search.order.1=Google
>> browser.search.order.2=Yahoo
> these properties keys refers to SP name attribute, and make the search
> bar context menu looking bad (is not useful for 99% Italian users to see
> .it extension to almost all included SP when it is obvious that a
> localized version of FX contains localized SP...).
I wonder what this has to do with it. Yes, if you change the name of the
search plugin, you have to adjust browser.search.order foo.
>
> So please don't ask us to rename SPs in Google.it, eBay.it... manner,
> but require to us only the difference in the file name. Please leave us
> the decision of opportunity to modify the SP name attribute for each
> locale.
So you just dismiss the usecase of multiple lang installs? I for one
have at least two wikipedia plugins installed.
Axel
Michele Dal Corso
> Michele Dal Corso wrote:
>> Renaming the actual Google plug-in in something like Google.it it add
>> only confusion between two versions of SP.
>
> How can having them be the same name be non-confusing?
I think it is a FX issue and not a locale issue: FX should manage better
SP whith same name:
* the simplest solution it is that FX adds a numeric estension to SP
name in SP menu for SPs with identical name:
Google
Google [2]
Google [3]
(in general how a creator of a SP can know if there is an SP in the
wild with same name but different content? Isn't a FX issue that FX
presents different SPs with the same identificator?)
* a better solution is to display the description attribute of each
SP for ambigous plug-ins (or just for all SP, eg. with a tooltip).
This will allow more control to SP's authors and localizers and
avoid potential conflict conditions.
> Note that if this is actually a problem to you, you could just use the
> google.com plugin, which should redirect to google.it and italian lang
> based on the users IP.
IP redirection performed by Google isn't so robust as forced laguage
parameter, eg. if a localized version is used abroad. Again it fails if
the user changes the default accept language for browser.
I'm asking for searching a better solution than forcing localizators to
rename their SPs.
Thank you,
Michele Dal Corso
Axel Hecht
> Axel Hecht ha scritto:
>> Michele Dal Corso wrote:
>
>>> Renaming the actual Google plug-in in something like Google.it it add
>>> only confusion between two versions of SP.
>>
>> How can having them be the same name be non-confusing?
>
> I think it is a FX issue and not a locale issue: FX should manage better
> SP whith same name:
> * the simplest solution it is that FX adds a numeric estension to SP
> name in SP menu for SPs with identical name:
> Google [2]
> Google [3]
Sorry, but this sucks. Why do something totally mystical when you can do
something reasonable.
Yes, "Google (Italy)" or "Google (Italian)" (in italian language, of
course, on indicating searching in the country, the other one giving the
language) may be providing more information than necessary when
installing just one, but is it really *that* bad that you need to come
up with numbers in angular brackets instead?
> (in general how a creator of a SP can know if there is an SP in the
> wild with same name but different content? Isn't a FX issue that FX
> presents different SPs with the same identificator?)
> * a better solution is to display the description attribute of each
> SP for ambigous plug-ins (or just for all SP, eg. with a tooltip).
> This will allow more control to SP's authors and localizers and
> avoid potential conflict conditions.
>
>> Note that if this is actually a problem to you, you could just use the
>> google.com plugin, which should redirect to google.it and italian lang
>> based on the users IP.
>
> IP redirection performed by Google isn't so robust as forced laguage
> parameter, eg. if a localized version is used abroad. Again it fails if
> the user changes the default accept language for browser.
>
> I'm asking for searching a better solution than forcing localizators to
> rename their SPs.
File a bug and see if we can get something better for 2.0.
For 1.5, we're stuck with what we have, and this includes disambiguating
the names.
I have heard about discussions to completely move away from those .src
files, maybe that can make up for some better UE.
Axel
Michele Dal Corso
> Michele Dal Corso wrote:
> Yes, "Google (Italy)" or "Google (Italian)" (in italian language, of
> course, on indicating searching in the country, the other one giving the
> language) may be providing more information than necessary when
> installing just one, but is it really *that* bad that you need to come
> up with numbers in angular brackets instead?
Because a solution like these leave the 99% of localized end users
(expecially in Italy), that are not polyglot as a localizer often is,
without the generally useless "(Italiano)" extension in their menu. The
power user/localizator can discern their plugins with a number (I know
that a number is a bad proposal, but I wrote this to propose something,
not for irritate you: other locales could use different names for their
regional plugins. Italy has not regions, except for Swiss it-ch that for
now hasn't regional contents).
> File a bug and see if we can get something better for 2.0.
>
> For 1.5, we're stuck with what we have, and this includes disambiguating
> the names.
>
> I have heard about discussions to completely move away from those .src
> files, maybe that can make up for some better UE.
Ok, no margins to accomodate this question. I will modify Italian SPs
another time following your tradermark imposals.
Michele Dal Corso
> Ok, no margins to accomodate this question. I will modify Italian SPs
> another time following your tradermark imposals.
I checked-in the necessary changes but I had another idea to resolve the
problem:
why not to leave the default SPs name attributes shipped with
localized Firefox untouched and change the SPs available on MyCroft or
FXCentral sites?
For example (Google):
* in FX in English: Google
* in FX in Italian: Google
* in FX in French: Google
* etc.
in MyCroft you will find:
* Google (en) [Google in English should also be renamed when
distributed]
* Google (it)
* Google (fr)
* etc.
It applies only for SPs shipped with the en-US build: Google, eBay and
Yahoo, so it shouldn't be complicated to rename these SP in MyCroft: if
a user can't find plugins with same name, the ambiguity is resolved and
English will not have the privilege of SP without extension.
Michele Dal Corso
Jesper Kristensen
is now? "Google" is an illegal name. "Google (American English)" or
"Google.en-US" or something likely will be required. It is important to
have consistency between en-US and the other locales. Leaving out the
language note in the en-US name only, will spread more confusion among
users, than having different language versions with the same name.
One opportunity for 2.0 could be to add the language in a separate
attribute, and display it only if more search plugins with the same name
exists.
Laurens Holst
I agree, and I think I speak on behalf of the nl-NL localisation group
when I say that I am not happy with this.
This puts us in a difficult situation, we could do this:
Google.nl
Yahoo NL
eBay.nl
nl.Bol.com
Van Dale Woordenboek
Wikipedia NL
The .nl thing looks reasonably nice, however it does not apply to all
search plugins. So when we do this, it looks like a mess. We can also do:
Google NL
Yahoo NL
eBay NL
Bol.com NL
Van Dale Woordenboek
Wikipedia NL
Which just looks bad and has unnecessary NL additions (this is our
current solution).
99% of the users will probably not want to search on the English
versions of those websites (with the exception of Wikipedia, I guess).
E.g. Google.nl is just Google.com but with the Dutch language and a
higher preference for Dutch sites in the search results, but it does in
no way exclude English pages from the search. Because of that, I do not
see any importance in adding NL to the plugin’s name, because there is
no reason to have both a Google.com and Google.nl plugin.
If it is somehow different for you, nice, but I’d say you’re not an
average user.
By the way, I’ve installed en-US builds on numerous occasions and I do
not have two sets of ambiguous search plugins, so I do not see how that
situation could arise. I think the problem only appears after the
decision that the search plugins must have a different name for each
localisation, and instead of fixing this problem that is caused by that,
we, the localisation teams, are supposed to live with it.
I think that this decision was made without properly considering the
localisation teams, which are put in a situation that en-US does not
have. When the decision makers are American, it is easy to ignore the
rest of the world.
I’d say the proper solution is to not show the en-US search plugins in
non-en-US locales, and/or if there are multiple locales of the same
search plugins installed, detect that and automatically add an [nl] or
[en] suffix or something. If that can’t be done, then just leave
everything the way it was and don’t require localisations to rename
their files. It worked perfectly the way it did.
~Grauw
--
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.
Axel Hecht
> What i am hearing is that the en-US won't get trademarks approval as it
> is now? "Google" is an illegal name. "Google (American English)" or
> "Google.en-US" or something likely will be required. It is important to
> have consistency between en-US and the other locales. Leaving out the
> language note in the en-US name only, will spread more confusion among
> users, than having different language versions with the same name.
>
Actually, google.com will do IP resolution to be tricky about language.
Hah :-).
I'm reading that this thing is not well accepted. Anyway, my use case
doesn't hold that high, as langpacks don't include search plugins right now.
So I'll drop that requirement, name the search plugins as you consider
it convenient. Though I still think that non-ambiguous names have their
benefit in general.
>
> One opportunity for 2.0 could be to add the language in a separate
> attribute, and display it only if more search plugins with the same name
> exists.
Axel
Laurens Holst
> Actually, google.com will do IP resolution to be tricky about language.
> Hah :-).
>
> I'm reading that this thing is not well accepted. Anyway, my use case
> doesn't hold that high, as langpacks don't include search plugins right
> now.
>
> So I'll drop that requirement, name the search plugins as you consider
> it convenient.
That’s great. Thanks.
> Though I still think that non-ambiguous names have their
> benefit in general.
If the search plugins contained explicit support for localisation (could
distinguish between the same search plugin for different languages,
etc), and there would be a less intrusive way to label the localisation
of a search plugin (e.g. a right-aligned greyed-out [nl] in the drop
down list), then yes, that would be better.
Using the plugin name for that is not the right place. First of all
because it is meta-information which can not be automatically extracted,
and it can thus not act on it.
Second because it is not part of the name but it is secondary
information, and as such is distracting if it is presented as part of
the name. For a Dutch person, Google is just Google, and eBay is just
eBay, and the fact that they enter it on the localised address is of
very little importance, as long as it’s in the Dutch language as they
would expect.
And finally, there’s no naming convention established at all (some
variants I’ve seen: Google NL, Google.no, Google (Italian), Google
(fr)), so as soon as you start mix multiple languages other than English
(which is given an advantage position because it needs no language
identifier in the title) it will start to look messy.
Basically, putting that information in the plugin name seems to me to be
just a workaround for the fact that there is no other mechanism for it.
If you think it is desirable to be able to make the distinction, then
the addition of a hreflang-like information field to the search plugins
would be a good start, followed by implementing a generic mechanism in
the search tool that automatically presents this field to the user in
the desired presentation for every localisation.
~Grauw
Laurens Holst
>> I'm asking for searching a better solution than forcing localizators
>> to rename their SPs.
>
> File a bug and see if we can get something better for 2.0.
https://bugzilla.mozilla.org/show_bug.cgi?id=314107
~Grauw
Axel Hecht
as first bits of Firefox RC1 are popping up on some ftp servers, the
binary bits are up, the complete updates, too. The incremental updates
still need some work.
The tinderboxens are set back to pull from the BRANCH, so you should be
able to see your recent changes in the following nightlies.
Axel
Axel Hecht
If you feel like testing incremental update,
<Chase> if you're running a 1.5b2 localized build, try shutting the
build down, go to defaults\pref\, and change the channel in
channel-prefs.js to say 'betatest'
[05:31] <Chase> when you restart your build and check for updates, it
should find an update from 1.5b2 to 1.5rc1
[05:31] <Chase> we plan to do testing tomorrow. if the testing looks
good, we'll make the updates live on the beta channel (which is the
default channel in 1.5b2).
Follow up here, please. And make sure you're not tripping on
https://bugzilla.mozilla.org/show_bug.cgi?id=314684
Thanks
Axel
Hasse
> If you feel like testing incremental update,
>
> <Chase> if you're running a 1.5b2 localized build, try shutting the
> build down, go to defaults\pref\, and change the channel in
> channel-prefs.js to say 'betatest'
> [05:31] <Chase> when you restart your build and check for updates, it
> should find an update from 1.5b2 to 1.5rc1
> [05:31] <Chase> we plan to do testing tomorrow. if the testing looks
> good, we'll make the updates live on the beta channel (which is the
> default channel in 1.5b2).
Updating the sv-SE build from 1.5 beta to 1.5 RC1 works OK on Linux. On
Windows, the update is successful, but the version number in Windows
Add/Remove program is still 1.4.1.
--
Hasse
Mozilla sv-SE L10n team
Gert-Paul van der Beek
> <Chase> if you're running a 1.5b2 localized build, try shutting the
> build down, go to defaults\pref\, and change the channel in
> channel-prefs.js to say 'betatest'
> [05:31] <Chase> when you restart your build and check for updates, it
> should find an update from 1.5b2 to 1.5rc1
> [05:31] <Chase> we plan to do testing tomorrow. if the testing looks
> good, we'll make the updates live on the beta channel (which is the
> default channel in 1.5b2).
>
> Follow up here, please.
Add/Remove Programms Dialog is also OK on Windows after the update.
Greetings,
Gert-Paul
Mozilla-NL
Alexander L. Slovesnik
02.11.2005 17:16 you wrote:
> If you feel like testing incremental update,
>
> <Chase> if you're running a 1.5b2 localized build, try shutting the
> build down, go to defaults\pref\, and change the channel in
> channel-prefs.js to say 'betatest'
> [05:31] <Chase> when you restart your build and check for updates, it
> should find an update from 1.5b2 to 1.5rc1
> [05:31] <Chase> we plan to do testing tomorrow. if the testing looks
> good, we'll make the updates live on the beta channel (which is the
> default channel in 1.5b2).
>
> Follow up here, please. And make sure you're not tripping on
> https://bugzilla.mozilla.org/show_bug.cgi?id=314684
>
> Thanks
>
> Axel
Updating Russian build from 1.5 beta 2 to 1.5 RC1 works OK on Windows.
--
Sincerely yours,
Alexander L. Slovesnik a.k.a. Unghost
==>Web-page: http://forum.mozilla.ru/
==>Jabber ID: a...@mozilla.ru
==>Gmail Talk ID: ung...@gmail.com
==>ICQ: 205497659
==>IRC: ircs://irc.mozilla.org:6697/mozilla-ru
Axel Hecht
> Axel Hecht wrote:
>> Hi,
>>
>> as first bits of Firefox RC1 are popping up on some ftp servers, the
>> binary bits are up, the complete updates, too. The incremental updates
>> still need some work.
>>
>> The tinderboxens are set back to pull from the BRANCH, so you should
>> be able to see your recent changes in the following nightlies.
>
> If you feel like testing incremental update,
>
Incremental update is now on the beta channel, all your b2 users should
be ready to go.
>
> Follow up here, please. And make sure you're not tripping on
> https://bugzilla.mozilla.org/show_bug.cgi?id=314684
>
This still holds but will be fixed for RC2.
I couldn't verify the software uninstall issue for the german version on
XP either.
Axel
filip
> Axel Hecht wrote:
>> Axel Hecht wrote:
>>> Hi,
>>>
>>> as first bits of Firefox RC1 are popping up on some ftp servers, the
>>> binary bits are up, the complete updates, too. The incremental
>>> updates still need some work.
>>>
>>> The tinderboxens are set back to pull from the BRANCH, so you should
>>> be able to see your recent changes in the following nightlies.
>>
>> If you feel like testing incremental update,
>>
>
> Incremental update is now on the beta channel, all your b2 users should
> be ready to go.
BT2->RC1 for fr windows and linux are ok.
Ph
Marek Stepien
> Follow up here, please. And make sure you're not tripping on
> https://bugzilla.mozilla.org/show_bug.cgi?id=314684
Polish incremental update works OK on Windows and Linux.
Screenshots here:
http://www.flickr.com/photos/69903184@N00/sets/1278995/
;-)
--
Marek Stepien <marcoos at aviary dot pl>
http://www.firefox.pl/
Axel Hecht
> Axel Hecht napisał(a):
>> Follow up here, please. And make sure you're not tripping on
>> https://bugzilla.mozilla.org/show_bug.cgi?id=314684
>
> Polish incremental update works OK on Windows and Linux.
>
> Screenshots here:
> http://www.flickr.com/photos/69903184@N00/sets/1278995/
> ;-)
>
You're my update-fan-boy of the day :-) .
BID Wen ShaoHua
Incremental update from Beta 2 to RC1 works fine on windows for Simplified Chinese.
Best Regards,
Holy