Si somos amig asterisco s no me tortures

Si somos amig asterisco s no me tortures.

Compañer@s , amig/s y cidadanxs en general incluir excluyendo no parece buena receta, ¿pensaste en l@s cieg*s que leen utilizando sintetizadores de voz cada vez que pretendes utilizar lenguaje incluyente?

No es difícil, se puede usar un lenguaje no excluyente en cuanto a genero sin excluir a las personas ciegas, ¿ven? También pude usar, les ciegues y de esa manera no torturo o excluyo a las personas con dificultades visuales.

Hay ejemplos para todo tipo de frase, pero esto no pretende ser un artículo técnico ni una tesis, solo y llamado de atención, ya que una vez comprendida la situación podremos defender una causa sin perjudicar otra, la red accesible también es una causa que merece atención.

Compartir

16 Comentarios

    1. Sería sencillo que esos procesadores incluyan esos caracteres y que no lean asterisco…

      Eso sí que sería útil…

      1. La idea es buena pero:
        ¿que sonido le ponemos?
        ¿como sabe el software cuando si tiene que leerlos?

        El método de equis, asterisco, arroba, también complica la vida a mucha gente sin dificultades visuales, que no saben con que sonido representar esos gráficos y la mayoría esculcamos lo que leemos.

        1. Reglas básicas… las normas del lenguaje las hacen los usuarios.

          Se me ocurre que si no hay separación se lea dos veces (masculino y femenino) ya que es la intención de la persona que escribe en ese momento.

          Si hay espacio, se puede leer «asterisco» .

          Es posible llegar a un consenso. No es necesario discriminar…. Hay otras alternativas y la gente puede seguir escribiendo como considere.

          1. Si no puede leerse como lo dirías hablando con normalidad entonces es un fracaso de la comunicación. Tener que inventar una neolengua y querer obligar a los demás a usarla, solo para contentar a los que se ofenden, es ridículo. La gente nunca dejará de ofenderse. El lenguaje debe ser lo más sencillo, directo y universal posible. Todo lo demás es postureo.

  1. El que gastéis tiempo en estas tonterías y aproveches ese tiempo delante de la terminal programando con el GCC y depurando con el GDB dice mucho de vosotros. Cuando la construcción impostada del lenguaje es más importante que los 0days, es que habéis dejado de ser hackers (si lo fuisteis alguna ves) y estáis dejando de lado la manera más fuerte, más potente de empoderaros. En fins, una lástima :-(

  2. Poneros en el lugar del otro. No leaís el artículo, escucharlo. Os lo ponen fácil con el audio del sintetizador que esta en la cabecera. Así, entenderéis mejor lo que quiere decir.

  3. Por esa regla de tres también eliminamos la nueva forma de usar el lenguaje tipo:

    :)
    XD
    o emoticono

    Es más sencillo darle un valor para el audio:

    :) = sonrisa
    XD= cara sonriente

    Y dejar a cada uno que hable como quiera. Sin imponer. Si existe gente que habla así y con esa forma de escribir quiere hacer énfasis en algo, no es un fracaso del lenguaje.

    Fracaso del lenguaje será si no adaptan esos caracteres para las personas ciegas. Se merecen saber que hay una corriente de personas que cuando escriben quieren enfatizar lo relativo a la inclusión de géneros. Sin intención de economía del lenguaje, con intención de inclusión del genero femenino en el lenguaje.

    1. Pero igualmente el uso de «@» o «x» carece de una representación fonética en el habla, mientras que la «e», pues eso, es una e; una cosa son los emoticonos, que para esos no hay alternativa práctica, y otra hacer les jilipolles, cuando hay alternativas perfectamente funcionales cuyo único contra es el tema de los traductores automáticos, que ahora mismo son algoritmos mas que trabajo manual por cierto. No hay soluciones perfectas pero si soluciones mas eficientes que otras, y que requieren menos trabajo de implementar.

  4. No es por meterme con nadie, pero usar la «e» («todes», «les humanes», etc) tiene otro problema. Y es que hay gente que nos lee usando traductores automáticos porque no entienden nuestro idioma, y los traductores normalmente no entienden las palabras al usar la «e» de la misma manera que no entienden los asteriscos y las equis, y así dichas palabras se quedan sin traducir. Personalmente prefiero tirar más de palabras neutrales, más de «personas tal» y menos de «los/las/les/l@s/lxs» y recurrir a lo segundo sólo cuando no queda más remedio.

    Estaría genial, sin embargo, que tanto los sintetizadores de voz como los traductores automáticos entiendan de este tema y así se acabaría un poco el problema.

    1. Mira, no había leído tu respuesta antes de comentar; si, el problema de los traductores existe, también existe el problema de que la mayoría de traductores son privativos o que funcionan como el culo, en ese contexto el que un extranjero tenga un cierto problema para traducir ciertas palabras no me parece especialmente problemático, hablamos de personas incapaces de leer, leyendo un idioma que no es el suyo, en lugares marginales donde se usa una forma de escribir nueva, no es algo que me preocupe especialmente; y por sobre todo teniendo en cuenta que para hacer una traducción eficiente hace falta tirar de IA y que a estas es tan fácil como meterle de un comando las equivalencias una vez la base de datos está hecha… me preocupa incluso menos.

  5. También podemos usar (si nos preocupan los traductores) ambos géneros para que los lean como cualquier palabra (amigos y amigas).
    Sea dicho que lo mas pesado de escribir un artículo no es añadir el masculino y femenino, sino el mero hecho de pensarlo, desarrollarlo y plasmarlo.

    1. Estoy de acuerdo que es una buena opción, aunque en mi opinión la segunda mejor opción, lo que se gana en simplicidad de implementación se pierde al ser una solución farragosa, y además, esto ya es cosa mía que supongo que a pocas personas importará, un desastre a la hora de hacer poesía (parte artística) o consignas (parte práctica).

Deja una respuesta a juansantiago Cancelar respuesta

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax