WEEK 1
1. Who's Who in Localization?
A major part of the class this week was to identify who does what in a typical localization request on the vendor side.
News for me, this part emphasized that quality is influenced by many roles, including those not traditionally labeled as “QA.” Sales influences quality by setting expectations and validating feasibility. Project managers influence quality through planning, communication, and vendor coordination. Linguists and reviewers directly execute quality-related tasks, but they do not operate in isolation. Before this class, to be honest, I often associate quality ownership too narrowly with execution roles, rather than seeing it as distributed across the workflow.
2. Quiz Reflection
The short quiz associated with this module exposed some gaps in my understanding of role boundaries. Reviewing this mistake reinforced an important lesson. From a quality management perspective, quality risks are often introduced before a project even reaches production. Intake, feasibility checks, and expectation-setting are quality-critical moments, even though they occur outside traditional QA processes. This correction reminded me that quality management starts earlier than we normally assume.
3. Who Is Responsible for Quality?
While Harry did not provide a definitive answer to this question in class, based on my own experience, I came away with the view that while quality-related tasks can be distributed, responsibility itself cannot be fully delegated. No single role can absorb total accountability, but quality also cannot be treated as “everyone’s job” in a vague sense.
Instead, responsibility for quality shifts across stages of the workflow. Different roles carry greater responsibility at different points, depending on where quality risks are most likely to be introduced.
WEEK 2
1. Quality Depends on Where You Sit
Harry shared an observation from our Week 1 homework which I found interesting and never had a chance to think before: when people describe quality as end users, they tend to describe it emotionally. When people describe quality as someone in the supply chain or production flow, they become more objective and requirement-driven.
True. Different people care about different quality aspects. Somethings are simply assumed by users, like safety, even if they do not list it as a “quality criteria”. If a client is not the final user of the localized product, their quality definition may be indirectly shaped by business goals, timelines, or internal processes rather than actual user experience. That creates a risk: we might satisfy the client’s stated expectations but still miss what our users actually need.
2. The Client Is Not the Final User, So “Quality” Has an Extra Layer
E.g., App or product UI localization where the company is the buyer but not the reader, versus cases like legal or internal documents where the buyer is also the user.
This matters because it changes how I interpret client feedback. When the client is not the end user, “quality” can sometimes mean internal usability, risk reduction, or operational fit. If I only chase linguistic perfection, I might miss what the business actually considers a successful outcome.
3. The Quality Guru
The core content of Week 2 was built around the pre-class video (https://www.youtube.com/watch?v=d7qpjsRbg6c) and the idea that quality has multiple definitions.
This was the first time in the course where “quality” stopped being a vague value word and became a practical negotiation problem. If quality can mean “fit for purpose” and also “free of defects,” then the real work is figuring out which one is driving decision-making for this specific project.
4. Turning “Quality” Into Follow-Up Questions
A big part of the class was asking: if a client says “I want a high-quality translation,” is that statement helpful. The answer was basically “not really,” unless we translate it into more clarified questions.
For example, asking directly about tone or narratives can backfire because the client may not be a linguist, or may expect us to infer tone from the source; Timeline expectations need to be specific, not vague ASAP, and PMs should build buffer rather than passing deadlines verbatim downstream.
