Aunque técnicamente no tienen fallos las taxonomías en su registro, es recomendable mantener una consistencia y a la vez minimizar el esfuerzo de predecir las URL que se conforman, tanto a páginas HTML, como a los endpoints que genera la API nativa de WordPress, al usar el valor 'show_in_rest' => true cuando registramos la taxonomía.

De este modo sugiero que las taxonomías queden con el prefijo pokemon- y en singular: weakness, resistant, type.

• Simplificar el slug para URL más manejable.
• Publicar automáticamente en REST.
• Aprovechar las metaboxes nativas de WordPress.
  Con esto me refiero a no fijar en código las opciones de cada taxonomía, sino dejar que se capturen con la propia UI de WordPress.

Hasta donde tengo entendido (no sé realmente porque no soy tan fan), los tipos, resistencias y debilidades no tienen una relación jerárquica o contenidos unos dentro de otros.

Por lo que el atributo de jerarquías de las taxonomías conviene ponerlo en false.

De momento para poder reproducir el ejemplo son necesarias solamente Weight y Height.

Es necesario incluir un header con formato específico para que WP pueda reconocer el plugin como tal, des/activarlo el admin, y llamar los archivos con las funciones para que hagan contacto con la API conforme a las acciones y filtros declarados.

En lugar de especificar en cada función de registro de taxonomías, endpoints, etc. un dominio distinto, lo usual es registrar todas las cadenas para traducción bajo un solo dominio, dentro del ámbito de un mismo plugin y/o tema.

De este modo las funciones de extracción de cadenas, concentran todas en un solo archivo más fácil de trabajar para el traductor.