Contribuir con módulos de Weblate¶
Además del repositorio principal, Weblate consta de varios módulos de Python. Todos siguen la misma estructura y esta documentación los describe a fondo.
Por ejemplo, esto cubre:
wlc, biblioteca de cliente en Python, consulte Cliente de Weblate
translation-finder, utilizado para descubrir archivos traducibles en el repositorio
language-data, definiciones de idioma para Weblate, consulte Definiciones de idioma
translate-toolkit, la biblioteca para manipular los archivos de traducción, originalmente biblioteca de terceros pero ahora mantenida por Weblate.
Extender definiciones del idioma incorporado¶
Las definiciones del idioma están dentro del repositorio language-data.
Puede agregar las definiciones de idioma que falten al archivo languages.csv, otros archivos son generados a partir de ese archivo. Las columnas del archivo CSV corresponden a Definiciones de idioma.
Licencia y derecho de copia¶
Cuando contribuya código, está de acuerdo con poner sus cambios y código nuevo bajo la misma licencia que el repositorio esté ya utilizando, a no ser que comenzó y acordó otro.
Ver también
Licencia de Weblate explica licencia con más detalles.
Escritura de un buen parche¶
Escribe cambios separados¶
Es molesto cuando obtienes un parche masivo que es dicho para reparar problemas extraños, pero discusiones y opciones no están de acuerdo con 10 de ellos o 9 de ellos ya estaban corregidos diferentemente. Entonces, la persona que fusiona este cambio tiene que extraer el único parche interesante de algún lugar dentro de la enorme pila de fuentes, y eso genera mucho trabajo adicional.
Preferiblemente, cada corrección que aborde una incidencia debería estar en su propio parche/commit con su propia descripción/mensaje de commit indicando exactamente lo que corrigen para que todos los cambios puedan ser aplicados selectivamente por el mantenedor u otras partes interesadas.
Además, los cambios separados permiten una disección mucho mejor para el seguimiento de incidencias y regresiones en el futuro.
Documentación¶
Documentar puede ser una tarea tediosa; sin embargo, es necesario que alguien la complete. Es mucho más fácil enviar la documentación junto con los cambios de código. Recuerda documentar los métodos, los bloques de código complejos o las funciones visibles para el usuario.
Ver también
Casos de prueba¶
Las pruebas nos permiten verificar rápidamente que las características funcionan correctamente. Para mantener y mejorar esta situación, todas las características y funciones nuevas que se añadan deben probarse en el conjunto de pruebas. Cada característica añadida debe contar con al menos un caso de prueba válido que verifique su funcionamiento según lo documentado.
Mensajes de consigna¶
Las consignas de Git deben seguir la especificación Conventional Commits.
Comprobación de tecleo¶
Cualquier código nuevo utiliza tipo de consejos PEP 484. Estamos utilizando mypy para comprobar (porque tiene un complemento de Django que realiza la comprobación del tipo de apps hechas en Django).
La base del código aún no está completamente cubierto por anunciaciones de tipo, pero algunos módulos ya son forzados para comprobación tipada en el CI.
Codificar estándar y enlazar el código¶
El código seguiría PEP 8 codificando líneas de guía y sería formateado utilizando formateador de código ruff.
Para comprobar la calidad del código, puede utilizar ruff, su configuración está almacenada en pyproject.toml.
La forma más sencilla de garantizar todo esto es instalar prek. Se trata de una re‐implementación de terceros de la herramienta pre-commit utilizada por Weblate. Está incluida en las dependencias de desarrollo declaradas en pyproject.toml, por lo que al instalar dichas dependencias, prek estará disponible.
Para comprobar todos los archivos manualmente, ejecute:
prek run --all-files
Si prefiere el pre-commit original del cliente, utilice la misma configuración desde .pre-commit-config.yaml.
Codificar con seguridad¶
Cualquier código escrito para Weblate debe crearse teniendo en mente los principios de seguridad por naturaleza.
Directrices de IA¶
Al contribuir con contenido al proyecto, nos autorizas a usarlo tal cual y debes asegurarte de tener permiso para distribuirlo. Al enviarnos un cambio, aceptas que el proyecto pueda y deba adoptarlo y redistribuirlo bajo la licencia del proyecto. Los autores deben ser conscientes de que tienen la responsabilidad de garantizar que no se envíe código sin licencia al proyecto.
Esto es independiente de si se utiliza IA o no.
Al contribuir con una solicitud de incorporación de cambios, siempre debe asegurarse de que la propuesta sea de buena calidad y se esfuerce al máximo, siguiendo nuestras directrices. Como regla general, si alguien detecta que la contribución se realizó con ayuda de IA, tendrá más trabajo por delante.
Podemos aceptar código escrito con la ayuda de IA en el proyecto, pero el código aún debe seguir los estándares de codificación, estar escrito con claridad, estar documentado, presentar casos de prueba y cumplir con todos los requisitos normales que tenemos.