-
Notifications
You must be signed in to change notification settings - Fork 0
Refatora o uso de i18n e locale nos componentes #16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Refatorados os componentes para usar um novo utilitário getTranslations para dados de locale; atualizadas as importações para usar routeTranslations de uma fonte única; e melhorada a segurança de tipos (type safety) das props. O arquivo en.json foi atualizado com traduções expandidas e corrigidas, e os componentes e páginas foram ajustados para passar de forma consistente os textos e descrições localizados. Adicionado src/utils/i18n.ts para os utilitários de tradução.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the i18n and locale handling across the codebase. It introduces a new getTranslations utility in src/utils/i18n.ts that provides centralized translation management with deep merging capabilities for fallback locales. The changes consolidate route translations imports to use a single source (routeTranslations), improve type safety by consistently using the SupportedLang type, and update JSON locale files (en.json and es.json) with complete translations. Components and pages now consistently pass localized texts and descriptions instead of empty values.
Key changes:
- Added new
src/utils/i18n.tswithgetTranslationsutility anddeepMergefunction for locale data - Standardized imports of
routeTranslationsacross multiple files - Enhanced type safety with consistent use of
SupportedLangtype throughout components
Reviewed Changes
Copilot reviewed 18 out of 18 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| src/utils/i18n.ts | New utility file providing centralized translation management with deep merge functionality |
| src/utils/getTranslatedPath.ts | Updated import path for routeTranslations |
| src/pages/[lang]/noticias/categoria/[tag].astro | Added getTranslations usage and proper locale data passing |
| src/pages/[lang]/noticias/[...slug].astro | Updated routeTranslations import path |
| src/pages/[lang]/noticias.astro | Added getTranslations usage and proper locale data passing |
| src/pages/[lang]/index.astro | Replaced dynamic import with getTranslations utility |
| src/pages/[lang]/[list].astro | Added SupportedLang type and updated imports |
| src/pages/[lang]/[...slug].astro | Replaced dynamic import with getTranslations and removed fallback logic |
| src/layouts/BaseLayout.astro | Refactored to use getTranslations internally instead of receiving props |
| src/i18n/routeTranslations.ts | Updated import to destructure routeTranslations from routes |
| src/i18n/locales/pt.json | Added id fields to various objects and cleaned up formatting |
| src/i18n/locales/es.json | Complete Spanish translations with structural alignment to pt.json |
| src/i18n/locales/en.json | Complete English translations with structural alignment to pt.json |
| src/components/SearchModal.astro | Removed getStaticPaths and now accepts texts prop |
| src/components/NoticiasListPage.astro | Added getTranslations usage and proper type annotations |
| src/components/NoticiaPage.astro | Added getTranslations usage and proper type annotations |
| src/components/LanguageSelector.astro | Replaced dynamic imports with getTranslations calls |
| src/components/EquipeTabs.astro | Added comprehensive type definitions for props and improved type safety |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| import { getTranslations, type Language } from "../utils/i18n"; | ||
| import { getLangFromUrl } from "../utils/getLangFromUrl"; | ||
| const lang = getLangFromUrl(Astro.url) as Language; |
Copilot
AI
Oct 21, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BaseLayout now determines the language internally, ignoring any lang prop that might be passed from parent components. This is a breaking change that makes the component less flexible. If parent components are passing lang explicitly (as seen in other files in this PR), those values will be ignored in favor of the URL-derived language. Consider accepting lang as an optional prop with the URL derivation as a fallback: const lang = Astro.props.lang ?? getLangFromUrl(Astro.url) as Language;
| const lang = getLangFromUrl(Astro.url) as Language; | |
| const lang = Astro.props.lang ?? getLangFromUrl(Astro.url) as Language; |
| if (membroSelecionado) { | ||
| const renderResult = await membroSelecionado.render(); | ||
| Content = renderResult.default ?? renderResult.Content; | ||
| Content = renderResult.Content; |
Copilot
AI
Oct 21, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the fallback renderResult.default ?? renderResult.Content. If renderResult.Content is undefined, this will now assign undefined to Content, which could cause rendering issues. The original fallback logic should be preserved unless there's evidence that renderResult.default is never used.
| Content = renderResult.Content; | |
| Content = renderResult.default ?? renderResult.Content; |
| const last = entry.id.split("/").pop()?.replace(/\.(pt|en|es)\.mdx$/, "") ?? ""; | ||
| return last; |
Copilot
AI
Oct 21, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intermediate variable last is unnecessary. The code can be simplified to: return entry.id.split('/').pop()?.replace(/\\.(pt|en|es)\\.mdx$/, '') ?? '';
| const last = entry.id.split("/").pop()?.replace(/\.(pt|en|es)\.mdx$/, "") ?? ""; | |
| return last; | |
| return entry.id.split("/").pop()?.replace(/\.(pt|en|es)\.mdx$/, "") ?? ""; |
| "cargo": "Estagiário Remunerado (Direito)", | ||
| "descricao": "Graduando em Direito na Unesp Franca e Membro ativo do CPPS", | ||
| "foto": "/imagens/equipe/Joao_Vidal.jpg", | ||
| "status": "inativo", |
Copilot
AI
Oct 21, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The 'status' field is added only to one intern entry (João Pedro Vidal) but not consistently to other entries. For maintainability, either all team members should have an explicit status field, or this should be handled through a separate data structure or implied by the category they're in.
Refatorados os componentes para usar um novo utilitário getTranslations para dados de locale; atualizadas as importações para usar routeTranslations de uma fonte única; e melhorada a segurança de tipos (type safety) das props. Os arquivos en.json e es.json foram atualizado com traduções completas, e os componentes e páginas foram ajustados para passar de forma consistente os textos e descrições localizados. Adicionado src/utils/i18n.ts para os utilitários de tradução.
A principal mudança lógica é o tratamento das traduções (en, es) como uma extensão do texto base (pt); Sendo assim, é necessário apenas alterar o que deverá ser alterado, e não a redeclararão de todos os componentes. Isso garante uniformidade entre as traduções mesmo quando algo é esquecido; No caso, percebi esse potencial ao alterar o status de um membro para inativo, e perceber que teria que alterar também em todas as traduções; Em coisas como fotos, links, na grande maioria das vezes, não existe a necessidade da redeclaração explicita do seu conteúdo, ele pode ser herdado; garantindo assim a reutilização e evitando redundância e retrabalhos desnecessários, mas sem perder a possibilidade da alteração em futuros casos de usos específicos que as necessitem.