Localization Support

[nico-bellante]

Good first issue once we have a system in place.

[gergzk]

What are the Microsoft-level requirements for Q3?

[nico-bellante]

"Garage"

[gergzk]

What is "Garage" - is there some list somewhere?

[nico-bellante]

That’s a good question. I still have yet to see even the Garage level accessibility reqs myself, let alone the localization ones.

[Zlatkovsky]

Can we get PM help to identify what those guidelines are?

• Michael (sent from my phone)

---

From: nico-bellante notifications@github.com Sent: Monday, August 20, 2018 9:51 PM To: OfficeDev/MakerIDE Cc: Subscribed Subject: Re: [OfficeDev/MakerIDE] Localization Support (#26)

That’s a good question. I still have yet to see even the Garage level accessibility reqs myself, let alone the localization ones.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOfficeDev%2FMakerIDE%2Fissues%2F26%23issuecomment-414549076&data=02%7C01%7Cmizlatko%40microsoft.com%7Cbe3f7b45687b4a92843b08d60721bda8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636704238831171045&sdata=PRqKNCNQ85e1RiPSgeeYh4Yw%2BDg71SxGCtB4srxUNhQ%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACIItTuN8El9aW9IZmKqz2OA1M9C2W8hks5uS5HIgaJpZM4VnWoj&data=02%7C01%7Cmizlatko%40microsoft.com%7Cbe3f7b45687b4a92843b08d60721bda8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636704238831181054&sdata=V1Pzb%2Fnz%2Be9GKyieHLrZe%2F0pn9VrkNZm66qoUktepfo%3D&reserved=0.

[Zlatkovsky]

For starters can just port over today's Script Lab localization logic

[Zlatkovsky]

Could also be postponed a bit, but would be a good thing to do, since Mourad the MVP had kindly ported all the Script Lab strings to German

[gergzk]

Moving to Milestone 1.5 per our earlier email/chat.

[Zlatkovsky]

Started a bit of work on it (with support for making "fake" string) while on the airplane. That work is stashed away at https://github.com/OfficeDev/script-lab/tree/zlatkovsky/localization-start

[gergzk]

Can you make sure you do this in a way that’s compatible with the office loc pipeline?

On Mon, Dec 31, 2018 at 12:42 PM Michael Zlatkovsky < notifications@github.com> wrote:

Started a bit of work on it (with support for making "fake" string) while on the airplane. That work is stashed away at https://github.com/OfficeDev/script-lab/tree/zlatkovsky/localization-start

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OfficeDev/script-lab/issues/26#issuecomment-450688824, or mute the thread https://github.com/notifications/unsubscribe-auth/AXsyQcSDDjrusK3k4V3MIrsRL5jZ4g4Nks5u-na8gaJpZM4VnWoj .

[Zlatkovsky]

Yep, for sure. There are several steps along the way:

1. Set up infrastructure on the JS side (e.g., to look up what is the Office current display language or setting value; to transfer this information from editor to runner; to have ability to have fake strings, which is what I have in that branch for now; etc)
2. Create an interface for the strings, as well as implementation files for each of the languages. That's the part that we'll want to make compatible with the loc pipeline, though I expect that JSON is one of the many formats they use -- so something like what we have today in Script Lab 2017, maybe as a flat JSON file, should work.
3. Tokenize all of the strings that we use all over the UI, to make use of the localization.

[gergzk]

The way you access the strings might be a bit different, and I doubt you’ll need the interface. The en-us bundle should serve as that. I would defer this work til after we have moved out build to azure

On Mon, Dec 31, 2018 at 1:36 PM Michael Zlatkovsky notifications@github.com wrote:

Yep, for sure. There are several steps along the way:

1. Set up infrastructure on the JS side (e.g., to look up what is the Office current display language or setting value; to transfer this information from editor to runner; to have ability to have fake strings, which is what I have in that branch for now; etc)
2. Create an interface for the strings, as well as implementation files for each of the languages. That's the part that we'll want to make compatible with the loc pipeline, though I expect that JSON is one of the many formats they use -- so something like what we have today in Script Lab 2017, maybe as a flat JSON file, should work.
3. Tokenize all of the strings that we use all over the UI, to make use of the localization.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OfficeDev/script-lab/issues/26#issuecomment-450692509, or mute the thread https://github.com/notifications/unsubscribe-auth/AXsyQe3WHLjQvvETIAbFhithholQBSx3ks5u-oN5gaJpZM4VnWoj .

[Zlatkovsky]

I put it into the "near-future" bucket for now. I'm not going to be working on it immediately, but at the same time, I don't think we should wait too long on this, since it is feature take-back; and since, if I do the initial setup, others can help contribute to the effort (esp with "3.", which will take some time).

The interface would still be useful for strong typing on the TS side (e.g., inside a React component, being able to do <div>{getString("ok")}</div>)

In my mind, the Office loc system is something we obviously need to scale out to the 20 or however many languages, but to get us back to the previously-localized state shouldn't require anything specific. And when I talked to Mat from Insights team, it sounded like they were essentially using the same thing that we were in Script Lab, even with the Office loc process. So I'll definitely look at what the Loc system requires, but I don't think we need to wait to be in Azure or to hook up with Office loc to do this work. Even just getting tokanization in place would already be a good thing to do ahead of time, rather than continuing to scatter English all over the React markup in a non-traceable way. It also would make it easier to have string review even for the English strings, to make sure that we are consistent with the Microsoft guidelines for UI.

[wandyezj]

Closing stale issues.