Please hold your pushes. Bug 482229: browser.search.siteSearchURL l10n policy
Staś Małolepszy
We were a bit surprised by the late Friday landing to bug 482229
<https://bugzilla.mozilla.org/show_bug.cgi?id=482229>. We're working
right now on a policy that will work well for all locale, including the
ones with different default search provider than Google.
Thanks for being on top of things to all of you who have already changed
their region.properties. However, please remember that we always ask you
not to commit any changes to region.properties without a review. There's
no use in backing them out right now. I'm going to go through all these
landings and verify them, and I will get back to you if there are any
issues.
For those of you who haven't yet landed the change to region.properties
from the bug, please *hold your pushes* for now while we're working on
the right l10n policy. Hopefully, the wait won't be long (1-2 days?).
Your feedback about this bug will be greatly appreciated, too. Do you
foresee any problems with using this URL and Google in your locale? Does
http://www.google.com/search?hl={YOUR_LOCALE_CODE}&q=site%3Amozilla-europe.org+firefox
always give good results in your language together with the interface in
your language?
Thanks again for understanding and don't hesitate to e-mail me or ping
me on IRC if you have questions.
Best,
Staś
--
Staś Małolepszy
Mozilla L10n driver
+48 600462291
+33 643800452
Marcelo Poli
> Your feedback about this bug will be greatly appreciated, too. Do you
> foresee any problems with using this URL and Google in your locale? Does
> http://www.google.com/search?hl={YOUR_LOCALE_CODE}&q=site%3Amozilla-europe.org+firefox
> always give good results in your language together with the interface in
> your language?
>
Replacing {YOUR_LOCALE_CODE} with "es" (no quotes), Google gives results
in spanish. With "es-AR" or "es-ar", Google gives results in english.
Ricardo Palomares Martínez
> Thanks for being on top of things to all of you who have already changed
> their region.properties. However, please remember that we always ask you
> not to commit any changes to region.properties without a review.
I don't remember such warning about region.properties; I'm not
questioning if it happened (I'm sure it did).
However, maybe I'm not the only one with memory leaks, ;-) so could we
think of a "marker" alas "LOCALIZATION_NOTE" to flag files that
shouldn't be altered without asking for review? That way, L10N tools
could pass the warning to localizers like me. Something like this:
For DTD files:
<!-- LOCALIZATION NOTE: REVIEW_REQUIRED -->
For Properties files:
# LOCALIZATION NOTE: REVIEW_REQUIRED
It would be a one-time change for restricted files in en-US, so it
wouldn't impose a high workload for developers to implement it.
Ricardo.
Mad Maks
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>
I have the same thoughts as Ricardo, i missed the warning and i think it
is a good id to put a warning in the files
Tim Maks
Axel Hecht
That would work for region.properties, probably. If our tools would
actually expose file-wide localization notes, I'm not sure any of them do.
The other half of the question would be that this doesn't work for
searchplugins/*, which are under review-required policy, too.
One could argue that this should hold true for brand.*, just that we
can't really review those as that requires language skills.
Axel
Ricardo Palomares Martínez
> On 23.03.2009 18:25 Uhr, Mad Maks wrote:
>> Ricardo Palomares Martínez wrote:
>>> However, maybe I'm not the only one with memory leaks, ;-) so could we
>>> think of a "marker" alas "LOCALIZATION_NOTE" to flag files that
>>> shouldn't be altered without asking for review? That way, L10N tools
>>> could pass the warning to localizers like me.
>>>
>> is a good id to put a warning in the files
>>
>> Tim Maks
>
> That would work for region.properties, probably. If our tools would
> actually expose file-wide localization notes, I'm not sure any of them do.
If MozillaTranslator can't bind a L10N note with a especific
key/entity, it binds it to the first one in the file. It is not
optimum, but at least it doesn't plain hide it.
OTOH, the point of adding a "REVIEW_REQUIRED" tag is allowing L10N
tool developers to implement such warnings. We're probably living the
best time in Mozilla L10N area regarding L10N tools support: there are
plenty of them and they are all maintained, if not very actively
developed.
> The other half of the question would be that this doesn't work for
> searchplugins/*, which are under review-required policy, too.
IMHO, comments for DTD and XML use the same syntax, so they could be
inserted into searchplugins/*.xml, too.
Bear in mind that I'm not thinking in a way to *enforce* review
request before committing, but to *remind* the localizer that he/she
should ask for it. We are all nice guys here and don't bypass the
rules except by mistake. ;-)
> One could argue that this should hold true for brand.*, just that we
> can't really review those as that requires language skills.
I'm afraid I can't provide a magical solution for that, besides
trusting localizers or seeking a second independent opinion in every
affected language. :-)
Ricardo
Toni Hermoso Pulido
Hi Marcelo,
I would dare to say that Google is only sorting out certain written
language variants (I suppose those which maybe are more distant) such as
pt-PT vs pt-BR and zh-CN vs zh-TW.
Take a look at:
http://sites.google.com/site/tomihasa/google-language-codes
es-ES and es-AR HTTP Accept languages are converted to es when
performing a Google search.
So, both 'es-ES' and 'es-AR' teams should simply use 'es' in this string.
Cheers,
--
Toni Hermoso Pulido
http://www.cau.cat
Toni Hermoso Pulido
>
> Your feedback about this bug will be greatly appreciated, too. Do you
> foresee any problems with using this URL and Google in your locale? Does
> http://www.google.com/search?hl={YOUR_LOCALE_CODE}&q=site%3Amozilla-europe.org+firefox
> always give good results in your language together with the interface in
> your language?
Hi Stas,
For ca locale (and I think also for eu ang gl, non-Spanish languages in
Spain) this is lamentably far from perfect for many popular searches.
If you take a look at the following searches:
http://www.google.com/search?hl=fr&q=site%3Amozilla-europe.org+firefox
http://www.google.com/search?hl=hu&q=site%3Amozilla-europe.org+firefox
http://www.google.com/search?hl=ru&q=site%3Amozilla-europe.org+firefox
you will notice that first hits are in hl locale language, and then,
either in English or high pagerank pages (I cannot tell, but English
pages are likely to have a higher pagerank anyway).
In 'ca', 'eu' or 'gl', first pages are surprisingly 'es' ones (that's
what I see, at least). It's actually more dramatic in 'eu' and 'gl' (in
this latter case, there are no Mozilla Europe pages to check, though).
http://www.google.com/search?hl=ca&q=site%3Amozilla-europe.org+firefox
http://www.google.com/search?hl=eu&q=site%3Amozilla-europe.org+firefox
http://www.google.com/search?hl=gl&q=site%3Amozilla-europe.org+firefox
I pressume that when using hl=ca, Google is actually doing something
such as hl=ca,es giving equal or very similar weights to each language.
I can understand Google reasoning of adding es searches in ca, eu, gl
ones, but their weighting is currently horrible. Compared to what is
done for other languages in the world, they are lowering preferred user
language in hits list.
Indeed, this is not a geobased criterion, but a language one. A person
in Perpignan (Northern Catalonia, France) using hl=ca searches get the
same ca,es hits as myself in Barcelona (Catalonia, Spain), which is a
far worse outcome for a common user in that region.
Mad Maks
> Your feedback about this bug will be greatly appreciated, too. Do you
> foresee any problems with using this URL and Google in your locale?
> Does
> http://www.google.com/search?hl={YOUR_LOCALE_CODE}&q=site%3Amozilla-europe.org+firefox
> always give good results in your language together with the interface
> in your language?
>
>
http://www.google.com/search?hl=nl&q=site%3Amozilla-europe.org+firefox
does give good results.
greetings
Tim Maks
Julen
> Al 3/23/09 5:25 PM, En/na Staś Małolepszy ha escrit:
>>
>> foresee any problems with using this URL and Google in your locale? Does
>> http://www.google.com/search?hl={YOUR_LOCALE_CODE}&q=site%3Amozilla-europe.org+firefox
>>
>> always give good results in your language together with the interface in
>> your language?
>
>
> For ca locale (and I think also for eu ang gl, non-Spanish languages in
> Spain) this is lamentably far from perfect for many popular searches.
>
...
>
> In 'ca', 'eu' or 'gl', first pages are surprisingly 'es' ones (that's
> what I see, at least). It's actually more dramatic in 'eu' and 'gl' (in
> this latter case, there are no Mozilla Europe pages to check, though).
> http://www.google.com/search?hl=ca&q=site%3Amozilla-europe.org+firefox
> http://www.google.com/search?hl=eu&q=site%3Amozilla-europe.org+firefox
> http://www.google.com/search?hl=gl&q=site%3Amozilla-europe.org+firefox
Toni,
Thanks for pointing this out. For 'eu' the situation is the same as you
describe, so this is not ideal.
I'm not sure how we can fix this as it seems something on the Google
side, and Google is not very friend of minority languages as ours :(
Julen.
Staś Małolepszy
> al., 2009.eko marren 23a 23:38(e)an, Toni Hermoso Pulido(e)k idatzi zuen:
>> In 'ca', 'eu' or 'gl', first pages are surprisingly 'es' ones (that's
>> what I see, at least). It's actually more dramatic in 'eu' and 'gl' (in
>> this latter case, there are no Mozilla Europe pages to check, though).
>> http://www.google.com/search?hl=ca&q=site%3Amozilla-europe.org+firefox
>> http://www.google.com/search?hl=eu&q=site%3Amozilla-europe.org+firefox
>> http://www.google.com/search?hl=gl&q=site%3Amozilla-europe.org+firefox
>
> Toni,
>
> Thanks for pointing this out. For 'eu' the situation is the same as you
> describe, so this is not ideal.
>
> I'm not sure how we can fix this as it seems something on the Google
> side, and Google is not very friend of minority languages as ours :(
Toni, Julen,
What happens if you don't specify the "hl" parameter at all? That is, if
you use:
http://www.google.com/search?q=site%3Amozilla-europe.org+firefox
Is the interface in English? What about the first results?
Thanks,
Julen
>
> What happens if you don't specify the "hl" parameter at all? That is, if you
> use:
> http://www.google.com/search?q=site%3Amozilla-europe.org+firefox
>
> Is the interface in English? What about the first results?
The result for me is the same as specifying "hl", i.e., interface in
Basque and Spanish results first.
Screenshot of the behaviour:
http://xs137.xs.to/xs137/09132/ggl_mzlerp825.png
Julen.
Staś Małolepszy
Sorry for keeping you waiting on this for longer than expected. We had
some outreach to the search providers to do in the dependencies and it
took some time. Thanks for being understanding and patient.
We tried to keep the policy regarding browser.search.siteSearchURL as
simple and flexible as possible. Your feedback is welcome, of course. It
was designed to handle any issues on the case by case basis -- we
figured this is a better approach than to try to predict and capture all
exceptions a priori.
The policy:
1. If the default search provider is not Google, then use their site
specific search. Site specific search feature is now a requirement for a
search engine to become a default in a locale. [1]
2. If the default search provider is Google, then:
2.1. Use
http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=site%3A{moz:domain}+{searchTerms}
(without the hard-coded locale code) and let Google do the language
detection.
2.2 If the language detection by Google is not satisfactory, use an
empty value for now to disable the pref and file a bug to investigate.
The bug should be filed in Mozilla Localizations > {your locale}. Please
CC st...@mozilla.com.
[1] Currently the only case here is Russian, I filed a bug for it:
https://bugzilla.mozilla.org/show_bug.cgi?id=485974
We're making an exception from the "no changes to region.properties
without review" rule for this single situation. Please land the
browser.search.siteSearchURL pref according to the above policy on
l10n-central and l10n-mozilla-1.9.1 in your locale. *No review is
required for this landing.* However, please only change this single pref
in your landings, so that we can refer to it easily later.
I will be monitoring the landings in the upcoming days, but hopefully
all goes smoothly and nicely :) Don't hesitate to ping me via e-mail or
on IRC if you have any concerns or to file bugs.
Thanks again for your patients and happy pushes! :)
Seth Bindernagel
Staś Małolepszy wrote:
> Hi all,
>
> Sorry for keeping you waiting on this for longer than expected. We had
> some outreach to the search providers to do in the dependencies and it
> took some time. Thanks for being understanding and patient.
>
> We tried to keep the policy regarding browser.search.siteSearchURL as
> simple and flexible as possible. Your feedback is welcome, of course.
> It was designed to handle any issues on the case by case basis -- we
> figured this is a better approach than to try to predict and capture
> all exceptions a priori.
>
> The policy:
>
> 1. If the default search provider is not Google, then use their site
> specific search. Site specific search feature is now a requirement for
> a search engine to become a default in a locale. [1]
>
> 2. If the default search provider is Google, then:
>
> 2.1. Use
> http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=site%3A{moz:domain}+{searchTerms}
> (without the hard-coded locale code) and let Google do the language
> detection.
>
> 2.2 If the language detection by Google is not satisfactory, use an
> empty value for now to disable the pref and file a bug to investigate.
> The bug should be filed in Mozilla Localizations > {your locale}.
> Please CC st...@mozilla.com.
I am relaying this tidbit from Stas with the hope that we provide just a
bit more complete information.
An empty value to disable the pref should look like this:
browser.search.siteSearchURL=
A good example of an empty value for this pref is here:
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/tr/rev/9c9e58147f56
-Seth
Staś Małolepszy
> The policy:
>
> 1. If the default search provider is not Google, then use their site
> specific search. Site specific search feature is now a requirement for a
> search engine to become a default in a locale. [1]
>
> 2. If the default search provider is Google, then:
>
> 2.1. Use
> http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=site%3A{moz:domain}+{searchTerms}
> (without the hard-coded locale code) and let Google do the language
> detection.
Oops, seems like there was a little copy&paste error involved here...
The correct URL should be:
(without the gfns=1 parameter)
Very sorry about this. For those of you who already landed, please fix
this without review.
Apologies,