Seo urls: permalink_fu o friendly_id

On Oct 15, 2008, at 7:33 AM, Xavier N. wrote:

normalize_for_url es un metodo propio que normaliza la cadena para que
quede limpia en una URL:

def self.normalize(str)
return ‘’ if str.nil?
n = str.chars.downcase.strip.to_s
n.gsub!(/[à áâãäåāă]/, ‘a’)
n.gsub!(/æ/, ‘ae’)
n.gsub!(/[ďđ]/, ‘d’)
n.gsub!(/[çćčĉċ]/, ‘c’)

Xavier,

En tiempos de Unicode, ahora que hay puntos de código, caracteres,
composiciones, descomposiciones, etc. creo que hacer eso “a mano” tal
vez no sea la mejor recomendación.

Saludos

2008/10/15 Adrián Mugnolo [email protected]:

En tiempos de Unicode, ahora que hay puntos de código, caracteres,
composiciones, descomposiciones, etc. creo que hacer eso “a mano” tal
vez no sea la mejor recomendación.

Te refieres a que el input puede venir en distintas normalizaciones?

On Oct 15, 2008, at 10:30 AM, Xavier N. wrote:

Te refieres a que el input puede venir en distintas normalizaciones?

Sí, eventualmente.

Un método como ese (que también los vi posteados por ahí) necesitaría
de mucho testing para dormir tranquilo. Quiero decir, eran cosas que
se hacían y estaban bien en tiempos de ISO-8859-1 adonde sabías
positivamente cuáles (y cuántos) eran todos los casos posibles. :slight_smile:

2008/10/15 Adrián Mugnolo [email protected]:

On Oct 15, 2008, at 10:30 AM, Xavier N. wrote:

Te refieres a que el input puede venir en distintas normalizaciones?

Sí, eventualmente.

Un método como ese (que también los vi posteados por ahí) necesitaría
de mucho testing para dormir tranquilo. Quiero decir, eran cosas que
se hacían y estaban bien en tiempos de ISO-8859-1 adonde sabías
positivamente cuáles (y cuántos) eran todos los casos posibles. :slight_smile:

Sí en eso tienes razon.

Las regexps en Ruby 1.8 saben algo de Unicode, pero no creo que tenga
soporte completo para equivalencias. No me consta ningun problema en
los dos años que hace que uso esa transliteracion, pero no es prueba
de que sea robusta ante cualquier input. De hecho tratare de buscar un
contraejemplo porque creo que debe haberlo.

2008/10/15 Xavier N. [email protected]:

Las regexps en Ruby 1.8 saben algo de Unicode, pero no creo que tenga
soporte completo para equivalencias. No me consta ningun problema en
los dos años que hace que uso esa transliteracion, pero no es prueba
de que sea robusta ante cualquier input. De hecho tratare de buscar un
contraejemplo porque creo que debe haberlo.

Eso lo teneis testeado?

2008/10/15 Francesc E. [email protected]:

2008/10/15 Xavier N. [email protected]:

Las regexps en Ruby 1.8 saben algo de Unicode, pero no creo que tenga
soporte completo para equivalencias. No me consta ningun problema en
los dos años que hace que uso esa transliteracion, pero no es prueba
de que sea robusta ante cualquier input. De hecho tratare de buscar un
contraejemplo porque creo que debe haberlo.

Eso lo teneis testeado?

No con todas las normalizaciones posibles.

2008/10/15 Xavier N. [email protected]:

No con todas las normalizaciones posibles.

Visto. Habia tres caracters en los que la normalizacion de la
aplicacion dependia de la normalizacion Unicode del input, eran: ą, į,
ij.

He añadido ligaduras y la letra ß a la transliteracion. He factorizado
tambien la tabla para poder automatizar esto sin repetirla en el test
(es posible que en codigo final cachee las regexps en lugar de
interpolar).

Os paso el modulo y el test abajo, son 120 aserciones.

– fxn

test/unit/normalization_test.rb

require ‘test_helper’

class NormalizationTest < ActiveSupport::TestCase
def test_normalization
MyAppUtils::TRANSLITERATIONS.each do |from, to|
expected = to * from.chars.length
ActiveSupport::Multibyte::NORMALIZATIONS_FORMS.each do |f|
normalized_from = from.chars.normalize(f)
assert_equal expected, MyAppUtils.normalize(normalized_from)
end
end
end
end

lib/my_app_utils.rb

module MyAppUtils
TRANSLITERATIONS = {
“à áâãäåāăą” => ‘a’,
“ß” => ‘ss’,
“æ” => ‘ae’,
“ďđ” => ‘d’,
“çćčĉċ” => ‘c’,
“èéêëēęěĕė” => ‘e’,
“Æ’” => ‘f’,
“ff” => ‘ff’,
“fi” => ‘fi’,
“fl” => ‘fl’,
“ffi” => ‘ffi’,
“ffl” => ‘ffl’,
“ſt” => ‘st’,
“ĝğġģ” => ‘g’,
“ĥħ” => ‘h’,
“ììíîïīĩĭį” => ‘i’,
“ij” => ‘ij’,
“ıĵ” => ‘j’,
“ķĸ” => ‘k’,
“łľĺļŀ” => ‘l’,
“ñńňņʼnŋ” => ‘n’,
“òóôõöøōőŏŏ” => ‘o’,
“Å“” => ‘oe’,
“ŕřŗ” => ‘r’,
“śšşŝș” => ‘s’,
“ťţŧț” => ‘t’,
“ùúûüūůűŭũų” => ‘u’,
“ŵ” => ‘w’,
“ýÿŷ” => ‘y’,
“žżź” => ‘z’,
}

def self.normalize(str)
return ‘’ if str.nil?
n = str.chars.downcase.strip.to_s
TRANSLITERATIONS.each do |from, to|
n.gsub!(/[#{from}]/, to)
end
n.gsub!(/\s+/, ’ ‘)
n.delete!(’^ a-z0-9_/\-.')
n
end
end

2008/10/15 Xavier N. [email protected]

Jeroglíficos raros.

Acabo de descubrir nuevas letras. Me faltaría saber como se pronuncian.
Para los pocos casos en los que se da (salvo en el lenguaje cani, donde
los
chavales encuentran no se como una rosa en el utf-8), o me como el
caracter
o informo al usuario de las limitaciones. (al margen de tildes cedillas,
etc… que obviamente si convierto).

Por cierto, te falta este:
“” => “apple”

:stuck_out_tongue:

Ah, dandole vueltas al tema veo que quiza podria cambiar esta
aproximacion por usar el truco de la normalizacion Unicode +
tratamiento de excepciones a mano. Con este test como base vere lo que
supondria, os cuento las pesquisas.

2008/10/15 Guillermo [email protected]:

2008/10/15 Xavier N. [email protected]

Jeroglíficos raros.

Acabo de descubrir nuevas letras. Me faltaría saber como se pronuncian.
Para los pocos casos en los que se da (salvo en el lenguaje cani, donde los
chavales encuentran no se como una rosa en el utf-8), o me como el caracter
o informo al usuario de las limitaciones. (al margen de tildes cedillas,
etc… que obviamente si convierto).

Eso para algunas aplicaciones esta OK y naturalmente es una decision
que te corresponde y esta bien.

Yo lo hago de otro modo porque el nombre de una persona es muy
importante para mi y trato de respetarlo en la interfaz lo maximo
posible. Si se registra alguien con apellido Łos o Weierstraß
intentare por todos lo medios que su nombre aparezca lo mas entero
posible. Por eso que trato de tener una tabla controlada sabiendo lo
que mapeo (modulo la prueba que os dije antes que hare).

Para que se entienda la posible percepcion del usuario, en WWR salvo
que lo hayan cambiado se cepillan letras acentuadas. Si uno ve que su
URL es 34-ngel-lpez pues… coño no esta fino eso para mi gusto. Es
algo tecnico pero yo prefiero que veas 34-angel-lopez en la medida de
lo posible, eso llevado a caracteres que se usan en otros paises
europeos.

2008/10/15 Xavier N. [email protected]

o informo al usuario de las limitaciones. (al margen de tildes cedillas,
etc… que obviamente si convierto).

Eso para algunas aplicaciones esta OK y naturalmente es una decision
que te corresponde y esta bien.

Yo lo hago de otro modo porque el nombre de una persona es muy
importante para mi y trato de respetarlo en la interfaz lo maximo
posible.

Depende del tipo de aplicación/cliente. A mi los usuarios me han
demostrado
que suelen pasar de la url. Creo que prueba de ello es el tono gris que
toma
todo lo que no es el dominio en google chrome. Al margen si es correcta
o no
esa filosofía, es una realidad que el usuario por sencilla que sea la
url,
va ha acabar copiando y pegando. 34-ngel-lpez, 34-angel-lopez o
34-%C3%81ngel-L%C3%B3pez, para al final, arrastrar el icono del
navegador al
email/messenger.

El otro motivo que podría existir es SEO. Pero la verdad, me parece que
se
le ha dado más importancia de la que tiene. Hace mil veces más un buen
contenido que el mejor de los seo.

Desde el punto de vista purista, te doy toda la razón del mundo, pero
siguendo las guías de diseño de apple (por poner algunas), utilizo la
regla
del 80/20. Cualquier funcionalidad válida solo para el 20% no me merece
la
pena. Me centraré en el 80% de los españoles que no tienen tílde en su
nombre (y eso que me discrimino). A lo que voy, que con poner solo las
tíldes y cedillas, ya soluciono el problema a mi 80% de usuarios. Al
resto,
sinceramente. ¡que les den!

Espero que mi respuesta no haya quedado muy hostil.

Un Saludo.

2008/10/15 Guillermo [email protected]:

Por cierto, te falta este:
“” => “apple”

Y este ☃ => ‘snowman’

http://☃.net/

El día 15 de octubre de 2008 23:08, Guillermo
[email protected]
escribió:> Depende del tipo de aplicación/cliente.

Tienes razón en esto, hay usuarios con un perfil muy distinto al de
los tuyos: al migrar los usuarios de una web anterior hemos tenido
varios casos en los que nos pedían actualizar el nombre de usuario y
además (explícitamente) el identificador de sus URLs.

Yo creo que además la URL gana peso en cuanto la sacas del navegador a
otro medio. Hay gente que aloja su web en algún servicio online y
siempre preferirá aparecer en sus tarjetas de visita o en las
reseñasde medios impresos como:

artistas.com/angel-lopez

en lugar de:

artistas.com/C3�ngel-López

Mi opinión sobre las urls y el seo es…

Las url cuanto mas cortas y mostrando menos palabras no 

significativas
mejor, por lo que quizás el tema de:
/category/pelis/post/los-supervillanos-de-texas/ sea peor que
/pelis/supervillanos-de-texas

Luego viene el tema de las stop-words :stuck_out_tongue:

La primera opción suele ser la más habitual para como trabajamos
normalmente en rails, pero si nos curramos un poco el routes y
redefinimos
algunos metodos como ya se ha comentado pueden quedar urls más simples
como
la segunda.

Todo esto depende de cual sea tu objetivo, si necesitas buen
posicionamiento
apuesta por la segunda, todo lo que valla detrás del login, es decir,
que no
sea público no tendría necesidad de configurar las url, a menos que sea
por
una elección estética o por mantener alguna coherencia que tu veas
necesária.

2008/10/15 Miguel Angel Calleja L. [email protected]

Vale, hecha la prueba con

n = str.chars.downcase.normalize(:kd).to_s
n.gsub!(/[^\x00-\x7F]+/, ‘’)

segun el test analogo al que envie antes se borra algun caracter de
cada una de estas asignaciones (12 sobre 30):

#'ß'          => 'ss',
#'æ'          => 'ae',
#'ďđ'         => 'd',
#'Æ’'          => 'f',
#'ĥħ'         => 'h',
#'ıĵ'         => 'j',
#'ķĸ'         => 'k',
#'łľĺļŀ'      => 'l',
#'ñńňņʼnŋ'     => 'n',
#'òóôõöøōőŏŏ' => 'o',
#'Å“'          => 'oe',
#'ťţŧț'       => 't',

Entre esto y que el mapping es explicito creo que seguire usando el
mapping.