Draft standardized worflow for manual projects in Smartling

[gueroJeff]

Each content type has a spreadsheet file containing instructions for the project preparers and the l10n PMs. This content should be migrated to Mana (for project preparers) and the l10n-drivers documentation for the L10n PMs, in order to maintain documentation consistency.

• [x] Email
• [x] Snippets
• [x] Surveys
• [x] Legal markdown
• [x] Blog
• [x] SUMO articles
• [x] App store

Each content type should have its own page in mana and the l10n doc repo. These are some of the information that this needs to include. The audience is the l10n-driver PM team as well as anyone of our internal clients looking to understand how the process works.

• Content type files templates
• Pre-processing needs
• Workflow within Smartling
• • Manual (intake -> execution -> delivery -> internal review -> finalization - review feedback to Smartling?) -
• Filtering and parsing (regex)
• Post-processing needs
• Review feedback to update TM
• Archival

[peiying2]

Draft of the overall process. The non-standard internal review process and feedback loop need to be tested and confirmed. @gueroJeff please review when you feel better.

Note, I indicate the links to some of the existing docs we created. Once they have a permanent home, we can insert them.

[peiying2]

@gueroJeff please +r when you get chance. See if the flow is clearly described. The doc covers the area that the content-type process doesn't covered, such as filing the bug, Mozilla review process.

[peiying2]

Also, the Legal markdown is fully supported and it is a matter of setting up the connector with the legal repo.

However, as I mentioned in the issue for Legal template, there are two types of legal requests, one is through the Legal repo, another is a Word file based one-off request. It usually is limited to a few locales for 1) internal consumption; 2). breach alert.

[gueroJeff]

Thanks Pei. I know you were waiting on a template from me last week. Sorry I wasn't able to provide one by Friday. This morning, I started writing up a template that we can copy/paste into Mana for each content type page. I'll keep working on it tonight and tomorrow. What do you think?

This is a good start in terms of content. I think we need to make some changes though to reflect what we'd discussed about having one Mana page per content type linked from the Localization parent Mana page. We'll need to make sure it only contains information aimed at project preparers.

On the other side, we'll need to adapt these steps for the l10n-driver documentation. Maybe what we can do is publish the requestor doc first and ask flod/delphine if they want their documentation structured in the same way (parent page -> children pages by content type). What do you think of that?

[peiying2]

Yes, agreed. I feel like we need to have basic feedback on structure/organization on the content, and then you and I can focus on the accuracy of the content, and fill in the info based on the structure.

[gueroJeff]

Awesome. Let's use my doc as the template for mana and your doc as the templates for l10n-drivers doc. Take a look at my Mana page template tomorrow and let me know what you think.

[gueroJeff]

Here's an example of the Mana template applied in Mana.

[gueroJeff]

@peiying2 I'm creating all of the Mana pages and migrating the content for each. I've been combining snippets + in-app messages into one category, and I see now that you have them split out. Looking at the templates, they're effectively the same structure and use the same directives. Is there any reason to not combine them into one content type and one set of instructions/template?

[peiying2]

@peiying2 I'm creating all of the Mana pages and migrating the content for each. I've been combining snippets + in-app messages into one category, and I see now that you have them split out. Looking at the templates, they're effectively the same structure and use the same directives. Is there any reason to not combine them into one content type and one set of instructions/template?

They are not and should stay separate:

• Snippet, at project level (or job on Smartling) has one standard character limitation.
• In-app messages have multiple character limits - 1) Subject and 2) short description (both counts one cell/string limit) and 3). long description (the total of multiple cells/strings count). This one is very important for the mobile message. Take a look of the template.

[gueroJeff]

@peiying2 I'm creating all of the Mana pages and migrating the content for each. I've been combining snippets + in-app messages into one category, and I see now that you have them split out. Looking at the templates, they're effectively the same structure and use the same directives. Is there any reason to not combine them into one content type and one set of instructions/template?

They are not and should stay separate:

* Snippet, at project level (or job on Smartling) has one standard character limitation.

That sounds like a difference for L10n PgMs though, not project requestors. I'm working on the documentation for the latter.

• In-app messages have multiple character limits - 1) Subject and 2) short description (both counts one cell/string limit) and 3). long description (the total of multiple cells/strings count). This one is very important for the mobile message. Take a look of the template.

I'm looking at both templates, and they're nearly the same (only observable difference is in cell D8 between the two templates). In the "push notifications" template, I'm not seeing the points you mention here that demonstrate the multiple character limits function unique to in-app messages. What should I be looking at instead?

[peiying2]

You can remove the Push notification. This is asked a lot, but we can use Snippet template for it.

Snippet should be labeled as Snippet because it can be used on mobile or desktop.

For the in-app mobile prod description template: https://docs.google.com/spreadsheets/d/1H9BnzK7AfY0a3LFARM3Rede7_0RBrn4Brs3mOHuZNtU/edit#gid=1218117366 - check rows 12 and 13. Each cell contains multiple strings. A column counts the characters in Source (also to confirm it is within the character limit shown in B), B column shows the limit for the target language.

Snippet/Push notification templates are much simpler. Usually a sentence or a short paragraph. Since I get requests for Push notification, we may want to include it in the title so requester knows where to look for the template.

[gueroJeff]

I think I see the confusion now. I’m talking about in-app messages, not App Store descriptions. I have those noted as being distinct. Thanks for clarifying that. It looks like we’re all good for this in Mana.

El El lun, dic. 14, 2020 a la(s) 2:19 p. m., Peiying < notifications@github.com> escribió:

You can remove the Push notification. This is asked a lot, but we can use Snippet template for it.

Snippet should be labeled as Snippet because it can be used on mobile or desktop.

For the in-app mobile prod description template: https://docs.google.com/spreadsheets/d/1H9BnzK7AfY0a3LFARM3Rede7_0RBrn4Brs3mOHuZNtU/edit#gid=1218117366

• check rows 12 and 13. Each cell contains multiple strings. A column counts the characters in Source (also to confirm it is within the character limit shown in B), B column shows the limit for the target language.

Snippet/Push notification templates are much simpler. Usually a sentence or a short paragraph. Since I get requests for Push notification, we may want to include it in the title so requester knows where to look for the template.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla-l10n/pm-projects/issues/249#issuecomment-744716792, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOXEZB4QMLVDQDRHDXNILLSUZ6NDANCNFSM4SWQNMOQ .