🐛 fix(docs): decode unicode escapes and fix encoding in pt/es translations

Author: henrythierrydev

es/exceptions/exception-layout-strategy.mdx

@@ -96,7 +96,7 @@ Usa el decorator cuando la propia clase de exception debería llevar un layout p
 
 ## Cuando mapear en configuración
 
-Mapea en *spraxium.config.ts* cuando la política de layout esta orientada por decisiones de producto como branding, tono de lenguaje o estrategia específica por entorno. Este es generalmente el mejor default para gobernanza a nivel de aplicación porque centraliza toda la lógica de presentación de error en un lugar, facilitando la gestión de cambios ya que puedes intercambiar la política de layout sin modificar ninguna clase de exception de dominio.
+Mapea en *spraxium.config.ts* cuando la política de layout esta orientada por decisiones de producto como branding, tono de lenguaje o estrategia específica por entorno. Este es generalmente el mejor default para gobernanza a nivel de aplicación porque centraliza toda la lógica de presentación de error en un lugar, facilitando la gestión de cambios ya que puedes intercambiar la política de layout sin modificar ninguna clase de exception de dominio.
 
 <Table variant="striped">
   <TableHead>
@@ -122,7 +122,7 @@ Mapea en *spraxium.config.ts* cuando la política de layout esta orientada por d
 
 ## Cuando usar override por instancia
 
-Usa el override por instancia solo para casos contextuales donde la misma clase de exception necesita renderizar de forma diferente dependiendo de condiciones de runtime. Ejemplos típicos incluyen comunicación temporal de incidentes, migraciones activas o experimentos de feature-flag donde la respuesta de error necesita cambiar sin modificar definiciones de clase o archivos de configuración. Como este nivel tiene la mayor prioridad en la cadena de resolución, tratalo como un camino de excepción intencional y documenta por que existe para evitar crear comportamiento implícito que es dificil de rastrear al depurar.
+Usa el override por instancia solo para casos contextuales donde la misma clase de exception necesita renderizar de forma diferente dependiendo de condiciones de runtime. Ejemplos típicos incluyen comunicación temporal de incidentes, migraciones activas o experimentos de feature-flag donde la respuesta de error necesita cambiar sin modificar definiciones de clase o archivos de configuración. Como este nivel tiene la mayor prioridad en la cadena de resolución, tratalo como un camino de excepción intencional y documenta por que existe para evitar crear comportamiento implícito que es dificil de rastrear al depurar.
 
 ## Ejemplo completo con embed personalizado
 

es/exceptions/exceptions-best-practices.mdx

@@ -28,11 +28,11 @@ export class InsufficientBalanceException extends SpraxiumException {
 }
 ```
 
-La interfaz *props* tipada es importante porque le da a los layouts y al logging acceso a datos estructurados en vez de un string opaco. Cualquier clave en el objeto *props* puede ser interpolada en el *message* usando sintaxis de llaves dobles, y los layouts reciben el objeto *props* completo para que puedan construir embeds ricos, formatear números o mostrar orientación contextual al usuario.
+La interfaz *props* tipada es importante porque le da a los layouts y al logging acceso a datos estructurados en vez de un string opaco. Cualquier clave en el objeto *props* puede ser interpolada en el *message* usando sintaxis de llaves dobles, y los layouts reciben el objeto *props* completo para que puedan construir embeds ricos, formatear números o mostrar orientación contextual al usuario.
 
 ### Lanzando la exception personalizada
 
-Usa la exception personalizada dentro de services, guards o handlers exactamente como cualquier exception built-in. El pipeline resuelve el layout, registra si está configurado y envía la respuesta automáticamente sin ningun código extra en el punto de lanzamiento.
+Usa la exception personalizada dentro de services, guards o handlers exactamente como cualquier exception built-in. El pipeline resuelve el layout, registra si está configurado y envía la respuesta automáticamente sin ningun código extra en el punto de lanzamiento.
 
 ```typescript filename="shop.service.ts"
 import { InsufficientBalanceException } from './exceptions/insufficient-balance.exception';
@@ -45,7 +45,7 @@ if (user.balance < item.price) {
 
 ### Vinculando un layout con @WithLayout
 
-Si la exception debe venir con una presentación visual por defecto, vincula un layout usando el decorator `@WithLayout` de *@spraxium/common*. El layout recibe la instancia de la exception con acceso completo a las *props* y el contexto de ejecución, y retorna un payload de respuesta de Discord con embeds, componentes y flags ephemeral.
+Si la exception debe venir con una presentación visual por defecto, vincula un layout usando el decorator `@WithLayout` de *@spraxium/common*. El layout recibe la instancia de la exception con acceso completo a las *props* y el contexto de ejecución, y retorna un payload de respuesta de Discord con embeds, componentes y flags ephemeral.
 
 ```typescript filename="insufficient-balance.exception.ts"
 import { WithLayout } from '@spraxium/common';
@@ -73,7 +73,7 @@ export class InsufficientBalanceException extends SpraxiumException {
 
 ### Controlando respuesta y comportamiento de logging
 
-Cada exception personalizada puede sobreescribir si el pipeline envía una respuesta en Discord y si registra el error en logs. La flag *shouldReply* por defecto es true, lo cual es correcto para fallas orientadas al usuario, y *shouldLog* por defecto es false porque la mayoría de las exceptions de dominio son comportamiento esperado en vez de incidentes. Sobreescribe esos valores por defecto cuando la exception represente una operación silenciosa o un error interno que debería aparecer en los logs operacionales.
+Cada exception personalizada puede sobreescribir si el pipeline envía una respuesta en Discord y si registra el error en logs. La flag *shouldReply* por defecto es true, lo cual es correcto para fallas orientadas al usuario, y *shouldLog* por defecto es false porque la mayoría de las exceptions de dominio son comportamiento esperado en vez de incidentes. Sobreescribe esos valores por defecto cuando la exception represente una operación silenciosa o un error interno que debería aparecer en los logs operacionales.
 
 ```typescript filename="silent-audit.exception.ts"
 export class SilentAuditException extends SpraxiumException {
@@ -130,7 +130,7 @@ Lanzar exceptions genéricas para cada escenario puede parecer más rápido al p
 
 <Steps>
   <Step title="Modelar clases por política de negocio">
-    Crea clases de exception alineadas con reglas reales de producto y escenarios orientados al usuario en lugar de layout de archivos o detalles temporales de implementación. Cada clase debería representar una categoría de falla significativa que el equipo pueda referenciar consistentemente en code reviews, dashboards de monitoreo e informes de incidentes.
+    Crea clases de exception alineadas con reglas reales de producto y escenarios orientados al usuario en lugar de layout de archivos o detalles temporales de implementación. Cada clase debería representar una categoría de falla significativa que el equipo pueda referenciar consistentemente en code reviews, dashboards de monitoreo e informes de incidentes.
   </Step>
   <Step title="Mapear layouts en el config central">
     Manten el comportamiento orientado al usuario estable para cualquier command o listener que pueda emitir la misma familia de falla. Centralizar mapeos de layout en *spraxium.config.ts* asegura que la misma clase de exception siempre renderice de la misma forma, sin importar que modulo la lance.

es/exceptions/exceptions-configuration.mdx

@@ -27,7 +27,7 @@ export default defineConfig({
 
 ## Donde encajan los layouts
 
-Los layouts pertenecen a la política de presentación de errores, y esta página se enfoca en configuración central, comportamiento de fallback y gobernanza a traves de mapas de config en lugar de detalles de implementación de layout. Para la estrategia completa de layouts cubriendo que son, como crearlos, la precedencia entre decorators y mapeos, y cuando usar overrides por instancia, consulta [Estrategia de Layout](/guide/exception-layout-strategy).
+Los layouts pertenecen a la política de presentación de errores, y esta página se enfoca en configuración central, comportamiento de fallback y gobernanza a traves de mapas de config en lugar de detalles de implementación de layout. Para la estrategia completa de layouts cubriendo que son, como crearlos, la precedencia entre decorators y mapeos, y cuando usar overrides por instancia, consulta [Estrategia de Layout](/guide/exception-layout-strategy).
 
 ## Configuración con mapeo por clase
 

es/exceptions/exceptions-overview.mdx

@@ -11,7 +11,7 @@ category: Exceptions
 
 En Spraxium, las exceptions no sirven solo para interrumpir el flujo de control cuando algo sale mal. Son el mecanismo que transforma tanto fallas técnicas como de dominio en comportamiento predecible para el usuario y señales operacionales utiles que ayudan a tu equipo a entender que paso y por que. Sin una capa de exceptions estructurada, cada handler termina inventando su propio estilo de respuesta de error, lo que lleva a UX inconsistente, logs ruidosos y resolución de incidentes más lenta en toda la aplicación.
 
-A medida que el bot crece, las fallas dejan de ser casos extremos y pasan a ser parte de la experiencia normal del producto. Los usuarios encontraran negaciones de permisos, límites de cooldown, argumentos inválidos y recursos no disponibles de forma regular. Una capa dedicada de exceptions asegura que todos estos escenarios produzcan respuestas consistentes, significativas y fáciles de mantener conforme el bot evoluciona con el tiempo.
+A medida que el bot crece, las fallas dejan de ser casos extremos y pasan a ser parte de la experiencia normal del producto. Los usuarios encontraran negaciones de permisos, límites de cooldown, argumentos inválidos y recursos no disponibles de forma regular. Una capa dedicada de exceptions asegura que todos estos escenarios produzcan respuestas consistentes, significativas y fáciles de mantener conforme el bot evoluciona con el tiempo.
 
 ## La clase base SpraxiumException
 
@@ -94,7 +94,7 @@ El framework incluye quince clases de exception que cubren los escenarios más c
 
 <DropdownGroup>
 <Dropdown title="ArgumentException: INVALID_ARGUMENT">
-  Reporta un argumento inválido con los valores esperado versus recibido. Esta exception se lanza por el pipeline de parseo de argumentos cuando un argumento de comando falla en la coerción de tipo o validación de restricción. El objeto *props* acepta campos *expected* y *received* para interpolación de placeholders.
+  Reporta un argumento inválido con los valores esperado versus recibido. Esta exception se lanza por el pipeline de parseo de argumentos cuando un argumento de comando falla en la coerción de tipo o validación de restricción. El objeto *props* acepta campos *expected* y *received* para interpolación de placeholders.
 </Dropdown>
 
 <Dropdown title="CommandNotFoundException: COMMAND_NOT_FOUND">
@@ -114,7 +114,7 @@ El framework incluye quince clases de exception que cubren los escenarios más c
 </Dropdown>
 
 <Dropdown title="GuardDeniedException: GUARD_DENIED">
-  Señala que un guard bloqueó la ejecución del comando con una razón opcional. Esta es la exception genérica de negación usada cuando un guard retorna `false` y ninguna exception más específica aplica. El objeto *props* acepta un campo *reason* describiendo por que se denegó el acceso.
+  Señala que un guard bloqueó la ejecución del comando con una razón opcional. Esta es la exception genérica de negación usada cuando un guard retorna `false` y ninguna exception más específica aplica. El objeto *props* acepta un campo *reason* describiendo por que se denegó el acceso.
 </Dropdown>
 
 <Dropdown title="GuildOnlyException: GUILD_ONLY">
@@ -150,13 +150,13 @@ El framework incluye quince clases de exception que cubren los escenarios más c
 </Dropdown>
 
 <Dropdown title="ValidationException: VALIDATION">
-  Reporta un valor de campo inválido con el nombre del campo y un mensaje de razón. Usa esta exception para fallas de validación de dominio que ocurren fuera del pipeline de parseo de argumentos. El objeto *props* acepta campos *field* y *reason* para reporte preciso de errores.
+  Reporta un valor de campo inválido con el nombre del campo y un mensaje de razón. Usa esta exception para fallas de validación de dominio que ocurren fuera del pipeline de parseo de argumentos. El objeto *props* acepta campos *field* y *reason* para reporte preciso de errores.
 </Dropdown>
 </DropdownGroup>
 
 ### Usando exceptions built-in
 
-Las exceptions built-in se importan desde *@spraxium/core* y se lanzan con un objeto de props opcional que adjunta contexto al error. El pipeline resuelve el layout basado en el mapeo de configuración, renderiza la respuesta al usuario y registra la falla si la política de logging lo requiere, todo automáticamente y sin código adicional en el punto de lanzamiento.
+Las exceptions built-in se importan desde *@spraxium/core* y se lanzan con un objeto de props opcional que adjunta contexto al error. El pipeline resuelve el layout basado en el mapeo de configuración, renderiza la respuesta al usuario y registra la falla si la política de logging lo requiere, todo automáticamente y sin código adicional en el punto de lanzamiento.
 
 ```typescript filename="shop.command.ts"
 import {
@@ -177,7 +177,7 @@ throw new MaintenanceException({
 
 ## Error como contrato, no como accidente
 
-Tratar una exception como contrato significa que cada falla relevante tiene intención explícita detras de ella, en lugar de ser una solución improvisada o una respuesta genérica. En vez de retornar mensajes de error vagos, defines clases de exception y layouts que representan escenarios concretos como permisos insuficientes, violaciones de cooldown, argumentos inválidos o recursos no disponibles. Este enfoque crea un vocabulario estable en todo el equipo donde los ingenieros pueden leer código e inmediatamente entender que falló, por que falló y como el usuario debería ser informado.
+Tratar una exception como contrato significa que cada falla relevante tiene intención explícita detras de ella, en lugar de ser una solución improvisada o una respuesta genérica. En vez de retornar mensajes de error vagos, defines clases de exception y layouts que representan escenarios concretos como permisos insuficientes, violaciones de cooldown, argumentos inválidos o recursos no disponibles. Este enfoque crea un vocabulario estable en todo el equipo donde los ingenieros pueden leer código e inmediatamente entender que falló, por que falló y como el usuario debería ser informado.
 
 El objetivo práctico es predictibilidad en todo tu bot. El mismo tipo de falla siempre debería producir la misma clase de exception, el mismo formato de respuesta y la misma señal operacional sin importar donde en el código se origina el error. Cuando ese contrato se mantiene de forma consistente, la depuración se vuelve más rápida, la experiencia del usuario permanece coherente y el equipo puede razonar sobre fallas sin leer cada handler individualmente para entender el comportamiento de error.