Fallback locales not taken into account for pseudoLocale

[um-synth]

Describe the bug
Hi.

When setting up a pseudo local I have a problem that instead of using values of fallback locale, pseudo local messages are generated from the ids. In our case ids are not the same as default values, which makes pseudo local language a bit useless.
Not sure if this is intentional or a bug? Following the documentation, I would consider that a bug.

To Reproduce
Our .linguirc setup:

{
  "locales": [
    "en",
    "en-PL"
  ],
  "sourceLocale": "en",
  "pseudoLocale": "en-PL",
  "fallbackLocales": {
    "en-PL": "en",
    "default": "en"
  },
  "catalogs": [
    {
      "path": "src/locales/{locale}/messages",
      "include": [
        "src"
      ]
    }
  ],
  "format": "po"
}

Please let me know if you need any additional information.

[sharonyogev]

Hi, this is because compileSingleKey uses the key and not the translation
But, when I tried to replace it with translation some of the translations failed the compilation process, for example:

• {count, plural, one {boy} other {# boys}} {count, plural, one {girl} other {# girls}}
• {class} {count, plural, one {boy} other {# boys}}

As I see it, there are 2 solutions:

1. try to fix the escaping in pseudoLocalize.ts - I think it will be hard/impossible to be bulletproof since the language is not regular (we need to count the number of { for example), but more than possible to fix most common issues
2. do the pseolocalization in compile.ts in the processTokens function, it's safer since it's after we parsed the message-format and we traverse the AST so we know the type of each token

What do you think?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sharonyogev]

Bump? Has anyone looked at it?

[um-synth]

Hi. Sorry - I moved fwd with formatjs for now, since that was quite painful not to have. Though - maybe I will find some time during next month to take a look how this could be done based on the suggestion from @sharonyogev.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.