Thank you for your contribution @Yaswant2006! We'll take a look and get back to you.

Unfortunately, I won't be able to comment on the quality of the translations, but one thing that stood out to me were the number of lines removed vs added.

Can you provide any reason for why that might be?

@ewaterman @awalkowiak I suspect that messages_pt.properties was a bit outdated (either in their repo or ours). Could you check to see we're starting from a version of messages_pt.properties that has the same number of lines as messages.properties?

In addition, @ewaterman created a good contributor guide doc for translating via Crowdin (https://openboxes.gitbook.io/contributor-guide/translations) but we might need to think through the manual approach (https://openboxes.gitbook.io/contributor-guide/translations#translate-directly-in-message.properties-files) a little bit more. In other words, we should add more explicit steps to ensure these PRs are successful.

As part of that we should add some conventions

• Translation PRs should probably be additive (we shouldn't be removing keys - unless that key is being removed from messages.properties as well)
• Come up with a convention for whether to leave the UTF-8 characters or encode them (i honestly have no idea which is better)

  - auth.alreadyHaveAccount.text=Já tem uma conta?
  + auth.alreadyHaveAccount.text=J\u00E1 possui uma conta?
  

• Ensure that if updating a message key / label that has a translation, we have a reason for why the change is necessary.
• Consider adding a GHA check to validate translation PRs based on any conventions we come up with
• Figure out how to steer users toward Crowdin for adding translations whenever possible

Almost forgot ... since this is for Brazilian Portuguese the translations should probably be added to messages_pt_BR.properties.

I agree that for a translation PR I'd want to see that:

1. We have new translations only, unless there's justfication for an existing message being removed
2. Any existing translations that are edited have a reason, else we leave them unchanged
3. Messages are not moved around in the file, they maintain the same order

From what I can tell, Crowdin does expect UTF-8 encoded properties files and messages.

@jmiranda your original comment in #3485 mentions UTF-8 encoded strings not working but it does look like it is working for the most part:

I also checked Chinese (which is UTF-8 encoded) and it appears to display correctly for the most part.

There are definitely some places where it doesn't appear to work though:

I don't believe the fact that we're using UTF-8 is the cause of these issues though so I think that's worth investigating but I suggest that we look into it in a separate issue.

For this task, I do think we want the actual UTF-8 string and not the \uXXXX version.

@Yaswant2006 @jmiranda does that make sense to you two?

As for, messages_pt_BR.properties, I made this comment in the other PR:

I'd agree it'd makes sense to add these to a messages_pt-BZ.properties file if we already had existing translations for these labels in messages_pt.properties, but since this is the first time these labels are being translated I think it's fine to just put them in messages_pt.properties. We can always create a messages_pt-PT.properties file later if we have portugal specific translations that we want to override these with

And I still stand by that. Since none of us know what translations are Brazilian-specific, I'd rather just continue adding to the general portuguese translation file until we need the distinction one way or the other.