Spanish command (spanish localization discussion maybe in spanish)

5 views
Skip to first unread message

Guillermo Movia

unread,
Jul 22, 2009, 11:03:51 AM7/22/09
to ubiqui...@googlegroups.com
Hi, i will try to write in english and spanish as well. Now, thanks to
Roberto, Jono, Mitcho and some other people, I'm using ubiquity in
spanish. I'm very happy with that. My only suggestion at this level is
with some commands (most social commands) that have the name or
depends in a website. Ask and Answers command (at least) depends
specificaly on websites with that name and they are translated in
spanish, losing that connection. But it's a problem if we don't
translated it, because nobody will use it in english. What do you
think it's the best approach? My first reaction is don't translated
it, but maybe it's better to find similar services in spanish.

Ahora en español, que me es más fácil :) Revisando la lista de órdenes
admitidas, vi que se habían traducido las órdenes Ask y Answers,
cuando responden directamente a sitios web que tienen ese nombre (no
tan sólo el servicio que dan). Mi primera reacción fue pensar que no
debían ser traducidos, pero no sé cuánta gente los usará si no lo
hacemos. ¿Les parece ver si logramos encontrar servicios parecidos en
español?

Guillermo

Roberto Muñoz

unread,
Jul 22, 2009, 12:51:24 PM7/22/09
to ubiqui...@googlegroups.com
On Wed, Jul 22, 2009 at 17:03, Guillermo Movia <guiller...@gmail.com> wrote:

Hi, i will try to write in english and spanish as well. Now, thanks to

This list is in English so i guess English is better. Besides, in english the developers can hear our complains :-)

Maybe a localized list per country is more effective.


Roberto, Jono, Mitcho and some other people, I'm using ubiquity in
spanish. I'm very happy with that. My only suggestion at this level is
with some commands (most social commands) that have the name or
depends in a website. Ask and Answers command (at least) depends
specificaly on websites with that name and they are translated in
spanish, losing that connection. But it's a problem if we don't
translated it, because nobody will use it in english. What do you
think it's the best approach? My first reaction is don't translated
it, but maybe it's better to find similar services in spanish.

 
I have asked myself this cuestion several times while translating.

What's the goal of l10n? merely translation? or is more than that and has to "import" the application to the folklore the country you are localizating to?

Maybe you are a Spanish user in USA and want to use Ask.com or Yelp (which only works with USA restaurants). Or you want to check for restaurants and reviews in 11870.com

IMHO we must only translate the words, the meaning of this words must be handle by the command author or user, if i am in Spain will use 11870 instead yelp.

I translated the meaning of some commands to remember it easily
Other thing we can do is add localized commands for our contries, and, in the settings page, sort them by country


In the other hand, the application names should be translated?for example, twitter, google, yelp...i guess no, but have doubts.

"mitcho (Michael 芳貴 Erlewine)"

unread,
Jul 22, 2009, 1:28:20 PM7/22/09
to ubiqui...@googlegroups.com, ubiqui...@googlegroups.com

> IMHO we must only translate the words, the meaning of this words
> must be handle by the command author or user, if i am in Spain will
> use 11870 instead yelp.

Roberto, I agree that it is best if the translations of builtin
commands should simply be translations, and this includes the non-
translations of service names like "ask" or "answers".

> I translated the meaning of some commands to remember it easily
> Other thing we can do is add localized commands for our contries,
> and, in the settings page, sort them by country

I agree that we should instead bundle locale-specific feeds which can
be turned on, like some Spanish commands including the 11870 service
you mentioned. We haven't done this yet with any locale, but it would
not be hard to do. Perhaps we should consider consolidating all the US-
centric commands (like yelp) into a "US" feed as well so it can be
easily turned off.

I'd love to get other's thoughts on this as well. ^^

mitcho

Guillermo Movia

unread,
Jul 22, 2009, 1:40:08 PM7/22/09
to ubiqui...@googlegroups.com
2009/7/22 "mitcho (Michael 芳貴 Erlewine)" <mit...@mitcho.com>:
>
>> I translated the meaning of some commands to remember it easily
>> Other thing we can do is add localized commands for our contries,
>> and, in the settings page, sort them by country
>
> I agree that we should instead bundle locale-specific feeds which can
> be turned on, like some Spanish commands including the 11870 service
> you mentioned. We haven't done this yet with any locale, but it would
> not be hard to do. Perhaps we should consider consolidating all the US-
> centric commands (like yelp) into a "US" feed as well so it can be
> easily turned off.
>
> I'd love to get other's thoughts on this as well. ^^

When we localize some Mozilla site, we have a lot of problem with this
part (I'm from es-AR's group, but some webpages has just es,
coordinated by all localization groups). Maybe in the US it's more
common have just one service for each search, but at least for all the
spanish locales could be very difficult to find a service that works
in Spain, Argentina, Chile and Mexico (just the locales availables at
this moment). I think that the better approach is that default
commands names that include a service (ask.com, answers.com) doesn't
change, and doesn't be localized.

Guillermo

>
> mitcho
>
>
> >
>

"mitcho (Michael 芳貴 Erlewine)"

unread,
Jul 22, 2009, 2:36:05 PM7/22/09
to ubiqui...@googlegroups.com, ubiqui...@googlegroups.com
>> I agree that we should instead bundle locale-specific feeds which can
>> be turned on, like some Spanish commands including the 11870 service
>> you mentioned. We haven't done this yet with any locale, but it would
>> not be hard to do. Perhaps we should consider consolidating all the
>> US-
>> centric commands (like yelp) into a "US" feed as well so it can be
>> easily turned off.
>>
>> I'd love to get other's thoughts on this as well. ^^
>
> When we localize some Mozilla site, we have a lot of problem with this
> part (I'm from es-AR's group, but some webpages has just es,
> coordinated by all localization groups). Maybe in the US it's more
> common have just one service for each search, but at least for all the
> spanish locales could be very difficult to find a service that works
> in Spain, Argentina, Chile and Mexico (just the locales availables at
> this moment). I think that the better approach is that default
> commands names that include a service (ask.com, answers.com) doesn't
> change, and doesn't be localized.

I apologize-- when I said "Spanish commands like 11870" I meant
commands for Spain, the country. We would indeed ideally have
different locale-based feeds for different Spanish speaking regions.

As or whether US-centric commands like yelp should be localized or
not, I do think it makes sense to do so given the abundance of Spanish
speakers in the US.

I hope that makes sense. :)

mitcho

> Guillermo
>
>>
>> mitcho
>>
>>
>>>
>>
>
> >

Blair McBride

unread,
Jul 22, 2009, 9:10:55 PM7/22/09
to ubiqui...@googlegroups.com
Locale/country specific commands definitely make sense. However, there
is the use case of travelling to another country, and wishing to use
commands/services specific to that region. So it would be great if it
were also available as opt-in. Could also try something crazy like
loading feeds based on geolocation data.

- Blair

Seth Bindernagel

unread,
Jul 23, 2009, 1:48:05 AM7/23/09
to ubiqui...@googlegroups.com

Blair McBride wrote:
> Locale/country specific commands definitely make sense. However, there
> is the use case of travelling to another country, and wishing to use
> commands/services specific to that region. So it would be great if it
> were also available as opt-in. Could also try something crazy like
> loading feeds based on geolocation data.
>

You may want to check with our web dev guys because I know geolocation
from IP addresses, for example, comes in very low on the list when
detecting what Firefox download should be offered to an end-user. I
think the rationale was that the data is a bit unreliable when trying to
pin down a user's preferences based on location.

Queltosh

unread,
Jul 23, 2009, 2:39:26 AM7/23/09
to Ubiquity i18n
Maybe the commands could have a "property" with the countries in which
work. So we can type "enable commands of Spain" and then have
available the commands for the country Spain. This could be even more
specific and do "enable commands for NY" and have the commands for
NewYork.

The problem of control the web with language (as Ubiquity video says)
is that l10n is a very important issue.

I will review all the Spanish .po files having in mind all of you have
said.



Seth Bindernagel ha escrito:

Jono

unread,
Jul 23, 2009, 2:46:11 AM7/23/09
to ubiqui...@googlegroups.com
I think any command name that's tied to a URL should keep that name
even in other languages. Of course, when there are local synonyms for
the same thing (e.g. in Japan, google is called グーグル or ググる -- still
"google" but in a different writing system) then those should be
accepted as synonyms as well.

In general, I would like to see us move away from using URLs as
command names per se and towards making them plugin/provider arguments
for commands -- e.g. "search using ask.com" instead of "ask". Then we
localize the "search using" part and leave "ask.com" alone, or add
localized synonyms, or add more plugin/provider arguments for services
that are popular in a specific region.

E.G. in China, it's likely there will be more demand for Baidu,
Taobao, and Youkou than Google, Ebay, and Youtube. On the other hand,
not everyone who would want to use Chinese-localized Ubiquity will
neccessarily be <i>in China</i>, so there is a difference between
language and locale. Does this imply separate settings for language
and for locale? Or does it simply mean that we should make Baidu and
Taobao and Youkou available everywhere, as "search using..."
arguments, and not attempt to steer people towards one service over
another?

--Jono

Jono

unread,
Jul 23, 2009, 2:47:19 AM7/23/09
to ubiqui...@googlegroups.com
I agree with Blair here -- when I was in Japan recently, I kept
getting annoyed with Google for redirecting me to google.co.jp based
on my geolocation. I don't think that's what we want to do.
--Jono

"mitcho (Michael 芳貴 Erlewine)"

unread,
Jul 23, 2009, 8:11:20 AM7/23/09
to ubiqui...@googlegroups.com, ubiqui...@googlegroups.com
What we could do, though, is a polite suggestion... Check the locale
and say "you might have moved to Japan. Would you like to turn on the
Japanese services command feed?" or "you just started using Ubiquity
in Japanese. Do you want to turn on the Japanese services command
feed?" Either way, though, I agree that language and locale are
markedly different in this way and I think that we should offer all
those locale-oriented services to all language users.

mitcho (Michael 芳貴 Erlewine)

Chris Hofmann

unread,
Jul 23, 2009, 10:09:43 AM7/23/09
to ubiqui...@googlegroups.com


On Wed, Jul 22, 2009 at 11:46 PM, Jono <jdic...@mozilla.com> wrote:

< snip >
 

In general, I would like to see us move away from using URLs as
command names per se and towards making them plugin/provider arguments
for commands -- e.g. "search using ask.com" instead of "ask".  Then we
localize the "search using" part and leave "ask.com" alone, or add
localized synonyms, or add more plugin/provider arguments for services
that are popular in a specific region.

<snip>

I think this is the right direction, and we mght want to consider  language  that looks like

  search for  [ search for terms ]   using  [feed provider]  

or 

  using [feed provider] search for [ search terms ]

rules:

- the "using [feed provider]" parts would ba optional
- it  would  default to a provider based on initial default setttings,
- the default could be updated based on geoip as suggested
- it could be overridden on the command line.
- the "using" and "search for" keywords would be translated
- maybe we could also allow they the user to create aliases for the keywords

providers come and go,  and are different across region and locale, but the language of the web changes less often...

-chofmann

Jia Mi

unread,
Jul 23, 2009, 8:50:32 PM7/23/09
to ubiqui...@googlegroups.com
> E.G. in China, it's likely there will be more demand for Baidu,
> Taobao, and Youkou than Google, Ebay, and Youtube. On the other hand,
> not everyone who would want to use Chinese-localized Ubiquity will
> neccessarily be <i>in China</i>, so there is a difference between
> language and locale. Does this imply separate settings for language
> and for locale? Or does it simply mean that we should make Baidu and
> Taobao and Youkou available everywhere, as "search using..."
> arguments, and not attempt to steer people towards one service over
> another?

Can the search engine usage being learned automatically in Ubiquity
which is mostly like Google omnione box URL bar? Like after I visited
or used the Baidu.com search engine or taobao.com, the search command
for Baidu or Taobao will be automatically created and the user then
can use it for searching. Maybe the command name can be created by
using the url/domain name or the title of the service(which may be
localized already), then maybe will be easier for creating localized
search services.

Best and Regards,
Jia Mi (米嘉)
Reply all
Reply to author
Forward
0 new messages