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.
This would need a bunch of research. I don't know what can be done. I know :willkg has thought about it a little.
Summary: Break down UI strings into smaller components → [research] Break down UI strings into smaller components
Moving to the next sprint.
Whiteboard: u=contributor c=general p= s=2013.24 → u=contributor c=general p= s=2013.25
Moving to next sprint during planning.
Whiteboard: u=contributor c=general p= s=2013.25 → u=contributor c=general p= s=2014.1
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.
Moving to the backlog. There are more things to figure out and decide.
Whiteboard: u=contributor c=general p= s=2014.1 → u=contributor c=general p= s=2013.backlog
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?
Moving 2013Q4 bugs to the Future since we didnt care enough about them in 2014Q1.
Target Milestone: 2013Q4 → Future
You need to log in before you can comment on or make changes to this bug.