Jump to content

API:Localización

From mediawiki.org
Revision as of 11:04, 16 May 2020 by Bartolocarrasco (talk | contribs) (Created page with "* $1 para mención de claves de parámetro, y también referencias a variables como $2.")
Versión de MediaWiki:
1.25
Gerrit change 160798

Esto documenta cosas específicas para la localización de la API de acción de MediaWiki (api.php).

Véase Localisation para ver comentarios generales acerca de MediaWiki localisation.

Archivos de mensajes

Los mensajes de localización para el núcleo de MediaWiki se encuentran debajo de includes/api/i18n.

Para las extensiones, los mensajes que son solamente usados para la documentación de la API y que la mayoría de los usuarios finales no ven, deben estar en un archivo separado usando los mecanismos normales para tener múltiples archivos. Ver el localización de documentación sobre adición de nuevos mensajes.

Mensajes de ayuda

Denominación

Los mensajes de ayuda para los módulos API tienen un espacio de nombres usando la "ruta del módulo", que es la cadena utilizada para el parámetro "módulos" de action=help. Para los módulos agregados a $wgAPIModules , esta va a ser la misma que la clave utilizada en esa matriz, mientras que para los módulos agregados a $wgAPIPropModules , $wgAPIListModules o $wgAPIMetaModules será esa clave con el prefijo "query +".

  • El mensaje de descripción, anteriormente devuelto por el método getDescription(), se ha dividido en dos: un mensaje apihelp-$path-summary con resumen de una-línea del módulo y una

apihelp-$path-extended-description que contiene cualquier documentación adicional a nivel-módulo. Estos pueden anularse con los métodos correspondientes, aunque los casos en que es necesario son raros.

    • Antes de la 1.30, se usaba un apihelp-$path-description mensaje. Esto se anuló implementando el método getDescriptionMessage(), pero los casos donde fué necesario fueron raros.
  • Los mensajes de descripción del parámetro, anteriormente devueltos por el método getParamDescription(), es apihelp-$path-param-$name (dónde $nombre es la llave de getAllowedParams()). Esto puede ser borrado configurando un valor ApiBase::PARAM_HELP_MSG en la estructura de datos devuelta desde getAllowedParams()
    • Parámetros con una descripción similar a "Cuándo más resultados estén disponibles, uso esto para continuar" tendría que utilizar api-help-param-continue en vez de redefinir un mensaje duplicado.
    • Clasificando los parámetros que toman los valores "más nuevos" y "más viejos" (con parámetros relacionados de "inicio" y "fin" ) tendría que utilizar api-help-param-direction en vez de redefinir un mensaje duplicado.
    • Los módulos que utilizan CSRF tokens para implementar needsToken() no necesitan parámetro para documentar el token; este es automáticamente manejado por ApiBase.
    • Varias constantes adicionales están disponibles para usar en getAllowedParams(); ver ApiBase para más detalles.
  • Los parámetros con una matriz para ApiBase::PARAM_TYPE pueden usar ApiBase::PARAM_HELP_MSG_PER_VALUE para especificar que cada valor esté individualmente documentado. Estos mensajes son por defecto apihelp-"$path"- paramvalue-"$name"-"$value". Si los mensajes se nombran de acuerdo con el valor por defecto, no es necesario asignar mensajes a valores en la matriz ApiBase:: PARAM_HELP_MSG_PER_VALUE (todavía tiene que existir pero puede dejarse vacío).
  • Todos los ejemplos tienen que tener un texto descriptivo. Nombres de mensaje tendrían que estar a lo largo de las líneas de apihelp-"$camino"-ejemplo-"$arbitrarySuffix".

Documentación de los mensajes

Al documentar los mensajes en qqq.json, usa las plantillas siguientes:

Formato de los mensajes

Todos los mensajes terminarían con un periodo, y ser frases gramaticales. Para los parámetros pasados a los mensajes por defecto, ver las plantillas enlazadas desde #documentación de Mensaje.

El uso semántico wikitext markup en mensajes:

  • ‎<var> para mención de claves de parámetro, y también referencias a variables como $wgMiserMode.
  • ‎<kbd> for the possible values of parameters, mention of parameters with values (including references to other modules), and the mention of the input values in example docs.
  • ‎<samp> for mention of keys or values in the API output.
  • ‎<code> for anything else that's computer code, e.g. "the max-age header" or "the page ‎<head>".
  • You don't need additional quotation marks when using semantic markup.

If you need to reference other API modules, pipe a link to Special:ApiHelp and the help formatter will do the right thing. For example, "[[Special:ApiHelp/query+tokens|action=query&meta=tokens]]" is used in the documentation for various token parameters. The Special:ApiHelp link properly renders as an in-page anchored link if it's on the same help page (example). Similarly, reference to MediaWiki configuration variables such as $wgMiserMode should link to the documentation on mediawiki.org.

Pages referenced in examples should generally not be linked, as these links are unlikely to exist on many wikis.

Errores y alertas

Errors are raised by calling $this->dieWithError( $messageObjectOrKey ); and the message can be localized in the usual way. Likewise for warnings with $this->addWarning( $messageObjectOrKey );. See API:Errores y advertencias for details.

Customarily API error messages have message keys starting with apierror- and warnings with apiwarn-.

Texto en respuestas de API

ApiBase, and thus all API modules, are also context sources. Messages should generally be accessed using $this->msg(), and the API module itself should generally be passed when an IContextSource is needed.

Messages should not be arbitrarily included in the output because a client might find it useful.

Mejorar las regionalizaciones en Translatewiki

You can add and improve API help message translations on translatewiki.net, in the same manner as other core MediaWiki messages. The relevant message groups include

Véase también