Migrate hardcoded strings to i18n vars

[marinaaisa]

Bug/issue #102139999, if applicable:

Summary

This PR migrates hardcoded strings into i18n vars, including translation files for Chinese and Japanese.

Dependencies

vue-i18n

Testing

Steps:

1. Add the following to theme-settings.json file at public folder

{
  "features": {
    "docs": {
      "i18n": {
        "enable": true
      }
    }
  }
}

3. Run npm run serve
4. Go to the bottom of the page and change the language in the locale selector
5. Assert that hardcoded strings are translated in Chinese and Japanese

Checklist

Make sure you check off the following items. If they cannot be completed, provide a reason.

• Added tests
• Ran npm test, and it succeeded
• Updated documentation if necessary

[marinaaisa]

@swift-ci test

[dobromir-hristov]

Good job, here are some thoughts:

1. Stitching sentences in general is a bad idea. Left commends on a few of the places, but I think we should rethink those a bit.
2. async load translations as future improvement would be nice
3. use user browser locale as a future improvement as well
4. How would this tie to the router?

[dobromir-hristov]

Maybe move this to the /plugins dir?

[marinaaisa]

Well, I implemented it in the same way as SwiftDocCRenderRouter is. What part of the code would you move to the plugins folder?

[marinaaisa]

Thanks for review it @dobromir-hristov !

• Stitching sentences in general is a bad idea. Left commends on a few of the places, but I think we should rethink those a bit.

I agree. I fixed them.

• async load translations as future improvement would be nice

That would be nice. I haven't implemented it yet because we have very few languages but I'll do it in the future.

• use user browser locale as a future improvement as well

Yes. We will be working on it in a different PR. It's out of scope for this one.

• How would this tie to the router?

This is also out of scope for this PR but working on it.

[marinaaisa]

@swift-ci test

[hqhhuang]

Looking great!! Just left a few minor questions/comments. Do we also need to update the headers to these files? 😅

[mportiz08]

So many changes! 😅 Nice work 🙌

I haven't had time to actually test this very closely yet, but I did a full pass on reviewing all the code (except for the tests).

One general comment I have is that it would be nice if we could come up with a more consistent way of naming the message keys. Maybe we could use the component name as prefixes or something where it's a little more obvious to mentally map the strings to how they're used. You've probably thought a lot about this already and have opinions on the naming scheme I'm guessing.

[marinaaisa]

Thanks for the great feedback, @hqhhuang and @mportiz08 !!

Do we also need to update the headers to these files? 😅

Oh no, I still need to update the headers 🫣
Edit: ✅ done

One general comment I have is that it would be nice if we could come up with a more consistent way of naming the message keys. Maybe we could use the component name as prefixes or something where it's a little more obvious to mentally map the strings to how they're used. You've probably thought a lot about this already and have opinions on the naming scheme I'm guessing.

I'm open to suggestions! Naming is always the most difficult part. Any ideas?

[marinaaisa]

@swift-ci test

[marinaaisa]

@swift-ci test

[mportiz08]

@marinaaisa can you sync this with the latest main and resolve the conflicts? Hopefully they're minor and easy to fix. I think we're ready to merge this tomorrow once that's done.

[marinaaisa]

@marinaaisa can you sync this with the latest main and resolve the conflicts? Hopefully they're minor and easy to fix. I think we're ready to merge this tomorrow once that's done.

Done! ✅

[mportiz08]

@swift-ci test

[mportiz08]

@swift-ci test

[mportiz08]

Looks good, but I ran into some integration issues that we'll need to figure out next week before we can merge this. I'll reach out offline.