939733 - [research] Break down UI strings into smaller components

Status: RESOLVED WONTFIX

(support.mozilla.org :: General, defect, P3)

Description

[Kadir Topal [:atopal]]

Today we have about 2000 strings or 12000 words in Kitsune. Assuming 20 seconds per word, it would take more than 65 hours to translate all strings. That's not something we can reasonably expect teams to engage in when all they want is to use the support forums. We should break down UI strings into functional components, so contributors can localize can be informed which parts need their attention.

Something like:

* KB
** user facing
** administration

* Support forums
** user facing
** administration

* Discussion forums
** user facing
** administration

etc.

It might make sense to use our existing /app structure or do something else. I'm assuming this will need some research. In that case, we can convert this bug.

The user story is: I as a localizer want to see what UI strings I need to localize to make use of parts of Kitsune, so I can offer users an experience in their language without spending time on translating things users will never see.

Comment 1

[Ricky Rosario [:rrosario, :r1cky]]

This would need a bunch of research. I don't know what can be done. I know :willkg has thought about it a little.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

My wild guess is that we can split things up into separate domains. Thus instead of having one messages.pot file, we'd have a .pot file per app. I think we can do this with tower configuration in settings.py because that's what splits things into javascript.pot and messages.pot already.

However, that's only one half of this. The other half is that we have to somehow make it so that all these .pot files can be translated in verbatim. Then we have to figure out how to load all the .mo files (one for each .po file) in the code so that all the strings are available.

Maybe instead of fiddling with the code to load all the .mo files, it's possible to add a merge step to our deployment so that it merges all the .po files into one .po file and then compiles that to a .mo file.

Anyhow, this is definitely tricky. Further, if we have to make changes in Verbatim this will take a lot longer and be a lot more difficult.

Comment 3

[Ricky Rosario [:rrosario, :r1cky]]

Moving to the next sprint.

Comment 4

[Ricky Rosario [:rrosario, :r1cky]]

Moving to next sprint during planning.

Comment 5

[Will Kahn-Greene [:willkg] ET needinfo? me]

I can't tell if the goal here is explicitly to break up all the strings into different Verbatim projects or whether the goal here is to provide a way for localizers to look at a subset of strings that are deemed important.

If we can keep things in the same Verbatim project, we might be able to add an additional context comment to all strings in specific apps. If Verbatim can filter on context (e.g. "Show me all the strings with "important" in the context."), then we might be able to do this trivially as a post-extract-and-merge step where a script goes through the messages.pot file and adds the appropriate context text to each string.

This hinges on whether we can adjust the context of the string (not the string itself!) in a way that someone can filter in Verbatim to get a subset of strings. I don't know if Verbatim can do something like that.

Comment 6

[Ricky Rosario [:rrosario, :r1cky]]

Moving to the backlog. There are more things to figure out and decide.

Comment 7

[Will Kahn-Greene [:willkg] ET needinfo? me]

We talked a bit about this on the call and I think we need to figure out the specific requirements in order to go forward with figuring out what we want to do.

1. How many different buckets do we need for strings? Is it just "critical mass to enable SUMO section xyz" and "everything else"? Are there multiple SUMO section xyzs that each have their own critical mass?

2. Do the buckets nicely lie along kitsune code app lines? For example, something like "Critical mass is the questions app and everything else is the other apps".

3. Is it likely we're going to change the buckets in the future?


Relatedly, once we figure all that out, what additional process bits are involved? When we developers change strings in the code, how do we know which bucket those strings go in? How does a localizer know when strings in one of the critical mass buckets are updated so he/she can translate it asap? Do we hold back changes which involve strings in a critical mass bucket that aren't yet translated in some set of languages?

Comment 8

[Ricky Rosario [:rrosario, :r1cky]]

Moving 2013Q4 bugs to the Future since we didnt care enough about them in 2014Q1.

Comment 9

[Seburo]

Closed as per https://blog.mozilla.org/sumo/2019/06/07/sumo-platform-roadmap/