Oi @fgmacedo,

Thanks a lot for your work!

Did you also have a chance to add Brazilian Portuguese support on the API side?
I couldn’t find it, and I want to make sure generated documents (invoices, credit notes, etc.) are properly translated as well.
Once that’s done, I’ll go ahead and test everything before releasing.

Just a heads-up: I’ll need to re-open this PR on my end due to a missing CI configuration that would otherwise block the merge. You’ll still be credited as the author of all the commits, of course.

Thanks again!

Hi @ansmonjol , I'm still working on the API side and a PR is coming soon.

Hi @ansmonjol , I've submitted a PR to the api side: getlago/lago-api#3872. Please let me know if something is missing.

Hey @fgmacedo,
Have you been able to test both Backend and Frontend together?
I switched to both branches but was not able to set my billing entity's "Document language" and received a 422 error with code not_a_valid_language_code
Does it work on your side?

Hi @ansmonjol , I was not able to find where to switch language for the frontend translation, but the change language for the invoice settings did worked:

Request (made by the UI as curl here):

curl 'https://api.lago.dev/graphql' \
  -H 'accept: */*' \
  -H 'accept-language: pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7' \
  -H 'apollographql-client-name: lago-app' \
  -H 'apollographql-client-version: 1.0.0' \
  -H 'authorization: Bearer ...' \
  -H 'content-type: application/json' \
  -H 'origin: https://app.lago.dev' \
  -H 'priority: u=1, i' \
  -H 'referer: https://app.lago.dev/' \
  -H 'sec-ch-ua: "Google Chrome";v="137", "Chromium";v="137", "Not/A)Brand";v="24"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-site' \
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36' \
  -H 'x-lago-organization: 365866a9-44da-416f-a388-7ef7ad168a7b' \
  --data-raw $'{"operationName":"updateDocumentLocaleBillingEntity","variables":{"input":{"id":"365866a9-44da-416f-a388-7ef7ad168a7b","billingConfiguration":{"documentLocale":"pt_BR"}}},"query":"mutation updateDocumentLocaleBillingEntity($input: UpdateBillingEntityInput\u0021) {\\n  updateBillingEntity(input: $input) {\\n    id\\n    billingConfiguration {\\n      id\\n      documentLocale\\n      __typename\\n    }\\n    __typename\\n  }\\n}"}'

Response:

{"data":{"updateBillingEntity":{"id":"365866a9-44da-416f-a388-7ef7ad168a7b","billingConfiguration":{"id":"365866a9-44da-416f-a388-7ef7ad168a7b-c1nf","documentLocale":"pt_BR","__typename":"BillingEntityBillingConfiguration"},"__typename":"BillingEntity"}}}

but the change language for the invoice settings did worked

Indeed, I was probably having set it up wrongly on my side, my bad!

I've pushed the fix on your BE branch fixing a locale key definition leading to error on document generation.

I'll check for some other documents and email, if they are well generated, and try to merge this asap!

Have to re-open the PR on our side otherwise the e2e CI will not pass
I'll keep you as commits author

Been re-opened and merged here #2298

Done! Thanks for your work @fgmacedo

@ansmonjol Thanks for integrating this!

Is there a way to change the frontend language in the UI?
I've search everywhere and was not able to figure out how.

I indeed check if the translations are right, by mocking the function getTranslations in front/src/core/translations/utils.ts and forcing the locale key to be pt_BR:

export const getTranslations: (locale: Locale) => Promise<Record<string, string>> = async (
  locale,
) => {
  locale  = 'pt_BR';
  let loadedTranslation: Translation

  // Translations are dinamically imported according to the selected locale
  try {
    loadedTranslation = (await import(`../../../translations/${locale}.json`)) as Translation
  } catch {
    loadedTranslation = (await import(`../../../translations/base.json`)) as unknown as Translation
  }

  return loadedTranslation
}

And it indeed changed the locale of the UI:

But I've found that initializeTranslations get the locale from local storage or defaults to en:

const internationalizationVar = makeVar<InternationalizationVar>({
  locale: getItemFromLS(LOCALE_LS_KEY) ?? LocaleEnum.en,
  translations: {},
})

export const getItemFromLS = (key: string) => {
  const data = typeof window !== 'undefined' ? localStorage.getItem(key) : ''

  try {
    return data === 'undefined' ? undefined : !!data ? JSON.parse(data) : data
  } catch {
    return data
  }
}

And there's no one ever calling setItemFromLS to update the locale (the updateIntlLocale or updateLocale).

The "change locale" feature is missing in the UI?

Indeed, we do not allow to change the interface translations today.
Those different locales are here for specific places of the app and documents, not the whole application's interface.

This is on our radar but have not been prioritised as of today.

Can you work on this? I’ve translated the entire UI (3,000+ keys) to reduce adoption friction for our finance team.

The easiest way to set the language for now is by opening the browser console and typing localStorage.setItem("locale", "pt_BR") — but this requires too much technical knowledge for non-tech users.

I also noticed that besides en, pt_BR is the only one fully translated.

Hi @ansmonjol, I've implemented a suggestion on how we can implement this, it's fully functional: #2302

Please let me know what do you think.