El bot de "enlace permanente" de GitHub arruinó silenciosamente el significado de mi publicación

Hace aproximadamente un año, publiqué un mensaje en la instancia de Discourse de GitHub que incluía varias URL del tipo “https://github.com/PROPIETARIO/REPO/tree/RAMA/ruta” para discutir cómo GitHub.com procesa dichas URL. Mi publicación recibió rápidamente una edición generada por el sistema con el mensaje “Enlace de GitHub reemplazado por un enlace permanente”, que parece provenir del plugin discourse-github. Aunque reemplazar el nombre de la rama por un enlace permanente al ID del commit actual puede ser una función útil en el caso común de una publicación que cita código específico, en el caso especial de discutir el procesamiento de URL de GitHub, la edición destruyó el significado de mi publicación. Tuve la suerte de notar la edición del bot de inmediato y, tras varias rondas de confrontación con el bot, finalmente encontré una solución alternativa añadiendo una etiqueta <span> para evitar que el patrón del bot coincidiera, de la siguiente manera:

https://github.com/PROPIETARIO/REPO/tree/<span>RAMA</span>/RUTA

Sin embargo, otros autores podrían no notar la edición del bot y quedarse con una publicación que confundiría a los lectores.

¿Cuál es la mejor solución para evitar ediciones no deseadas de enlaces permanentes de GitHub en una publicación específica? En general, siento que es incorrecto que los bots realicen ediciones automáticas que corran el riesgo de arruinar una publicación. Sería más seguro (1) preguntar al autor al guardar una publicación si los enlaces deben editarse o (2) que el bot añada un enlace permanente sin eliminar el enlace original. (Parece recordar haber visto algunos bots en otros sitios web, quizás Reddit, que añaden información sin borrar la existente.) Si los mantenedores de Discourse consideran esas opciones demasiado feas o demasiado laboriosas para acomodar un caso de uso poco común, algunas otras opciones podrían ser (3) mostrar un aviso después de guardar la publicación con un enlace a información sobre cómo el autor puede evitar las ediciones si es necesario, ya sea (a) un banner dedicado en la interfaz de usuario o (b) simplemente una línea de texto añadida por el bot al final de la publicación.

No estoy seguro de cuál sería el diseño más razonable para que el autor opte por no participar en las ediciones. La configuración de exclusión a nivel de sitio del plugin discourse-github basada en el destino del enlace no parece adecuada para este propósito. Quizás mi solución actual con la etiqueta <span> sea suficiente. Incluso si no se realiza ningún cambio en Discourse, espero que esta publicación haga que la solución alternativa sea más fácil de descubrir para los autores que noten el problema.

Nota: Anteriormente plantee este problema en el foro de GitHub porque asumí que el bot de “enlace permanente” era específico de la instancia de GitHub, pero un comentarista allí me informó de que se trata de una función general de Discourse, por lo que estoy planteando el problema aquí.

¡Gracias por su atención!

2 Me gusta

Creo que esta es una buena función, ya que las personas a menudo pegan enlaces a master y estos casi siempre se vuelven obsoletos con el tiempo. Sin embargo, debería ser posible pegar intencionalmente un enlace a una rama, ya que hay muchas razones válidas para hacerlo. Además, en general, esta función parece estar un poco rota: reescribe cosas que no debería y no analiza cosas que probablemente debería.

Aquí hay algunos ejemplos que podrían usarse como casos de prueba para solucionarlo:

  1. Enlace simple creado simplemente pegando una URL. Esperaría que esto se reescriba, y así es: subdomain-static/forums-enhancements.js at master · ClassicPress/subdomain-static · GitHub
  2. Enlace en formato Markdown de la forma [url](url). Esperaría que este enlace no se reescriba, porque he especificado explícitamente tanto el texto como la URL. En su lugar, el texto del enlace se reescribe y la URL del enlace no. Esto está roto: https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js
  3. URL encerrada en comillas invertidas. Esto no es un enlace y no debería reescribirse, pero lo es: https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js
  4. URL en un bloque de código con tres comillas invertidas. Esto no es un enlace y no debería reescribirse, pero lo es:
    https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js
    

Creo que solo el caso (1) mencionado anteriormente debería reescribirse. Esto haría que el comportamiento fuera más predecible y solo reescriba enlaces “simples”. Los enlaces donde se ha utilizado una estructura Markdown específica (que puede considerarse como una forma de expresar una intención específica) deberían dejarse intactos.

1 me gusta

¿Parece que esta función no está habilitada en meta.discourse.org?

FWIW, no estoy de acuerdo: creo que en (2) edición: el caso general de [texto](URL) (llámalo (2a)), la URL del enlace debería reescribirse de la misma manera que (1). (Estoy de acuerdo en que el comportamiento actual de reescribir el texto y no la URL está completamente roto). Tomo la decisión entre escribir (1) y (2a) basándome en si creo que es útil o molesto que la URL sea visible para el lector, no basándome en ninguna intención sobre si el enlace debe apuntar a la versión del código tal como está escrita o tal como se lee. Por supuesto, soy consciente del problema de los enlaces permanentes, así que creo uno yo mismo siempre que quiero uno. Pero, en general, si un administrador de Discourse decide habilitar el bot de enlaces permanentes, presumiblemente es porque piensa que la mayoría de sus usuarios no son conscientes del riesgo de que los enlaces basados en nombres de rama puedan corromperse, y no creo que el uso de la sintaxis de enlaces Markdown sea una gran señal de que un usuario determinado es consciente del problema pero quiere excluirse de que ese enlace en particular sea reescrito.

Pero creo que ambos solo estamos especulando aquí. Como usuario avanzado, no me importa mucho cuál sea el valor predeterminado, siempre y cuando pueda anularlo según sea necesario.

Sí, exactamente. Actualmente no hay forma de anularlo. Escribir [url](url) (el texto del enlace y la URL son exactamente iguales) sin duda sería una forma de indicar al bot que ese enlace no debe ser reescrito, porque no hay otra razón para escribirlo de esa manera.

La hay si quieres darle al enlace tu propio título en lugar de que se infiera de la URL de destino, es decir, [título](url). Darle un título al enlace no indicaría ninguna preferencia por la reescritura de URL, así que estoy de acuerdo con @mattmccutchen en que 1 y 2 deberían comportarse de manera consistente para la reescritura de URL.

Podría argumentarse que el título que coincide exactamente con la URL es una indicación de que no debería reescribirse, pero ¿y si un usuario quiere proporcionar un título y quiere que la URL no se reescriba? Debe haber algún otro método para especificar eso.

Algo que me viene a la mente sería un sufijo de título similar al tamaño de las imágenes incrustadas, aunque no estoy seguro de cómo lo descubriría un usuario.

Una imagen incrustada se puede dimensionar así:
![título|100x200](url)

Por lo tanto, el plugin discourse-github podría (presumiblemente) hacerse para buscar algo como esto:
[título|github-no-rewrite](url)

Ah, no me quedó claro que tu (2) se refería solo al caso especial en el que el texto y la URL son los mismos. Mi declaración era para el caso general en el que el texto y la URL pueden no ser los mismos; llamémoslo (2a) ahora.

En el caso (2), estoy de acuerdo en que es extraño reescribir la URL y no el texto, dejándolos inconsistentes, pero ISTM uno podría argumentar igualmente que si queremos evitar la inconsistencia, la mejor manera de hacerlo es reescribir tanto la URL como el texto en lugar de ninguno. Por lo tanto, no encuentro convincente el argumento para tratar (2) como una exclusión. Dado que deberíamos tener una exclusión que funcione para (2a), me inclinaría a simplemente dejar que los usuarios usen la misma exclusión para (2) y no complicar el diseño. (¿Creo que esta también fue la idea de Simon Manning?)

No estoy seguro de seguir esto correctamente (o si es posible), pero ¿podrías usar el escape de espacio como en el Inline PDF Previews - #45 by Johani? Entonces [ texto]( url) no reescribiría ni el texto ni la url, ¿y todo lo demás se cambiaría automáticamente?

Esta versión debería permanecer como está y no ser reescrita, déjame ver:

https://github.com/correctcomputation/checkedc-clang/blob/master-post-microsoft/clang/docs/checkedc/Setup-and-Build.md

escrito como:

<https://github.com/correctcomputation/checkedc-clang/blob/master-post-microsoft/clang/docs/checkedc/Setup-and-Build.md>

No es una prueba válida porque la reescritura de permalinks de GitHub está completamente deshabilitada en esta instancia de Discourse. (Me pregunto qué dice eso sobre esta función si está deshabilitada en la instancia “oficial” :upside_down_face:)

Si escribieras este ejemplo como un caso de prueba para replace_github_non_permalinks.rb / replace_github_non_permalinks_spec.rb en su lugar, creo que encontrarías que ese enlace también se reescribe.

1 me gusta