{"id":122,"date":"2026-08-14T18:09:14","date_gmt":"2026-08-14T10:09:14","guid":{"rendered":"https:\/\/oribridge.org\/blog\/?p=122"},"modified":"2026-08-25T15:18:49","modified_gmt":"2026-08-25T07:18:49","slug":"localization-readiness-checklist","status":"publish","type":"post","link":"https:\/\/oribridge.org\/blog\/localization-readiness-checklist\/","title":{"rendered":"Localization Readiness Checklist: When Is a Course Ready to Adapt for China?"},"content":{"rendered":"

A course owner has just sent a shared folder to a translator. There are recordings, slides, two quizzes, a workbook, and a note saying, \u201cLet\u2019s get a China version moving.\u201d The next question is usually treated as a production question: How long will translation take?<\/em><\/p>\n

It is a decision question first: Are we actually ready to start a bounded adaptation project?<\/em><\/p>\n

For this OriBridge readiness framework, treat a course as ready to begin a scoped adaptation workstream only when the team can name the first learner action, the course objects and learning surfaces in scope, who may approve changes, which asset route is assumed, and what still needs a dated test. If any of those is unknown, the right outcome is HOLD or ESCALATE\u2014not a larger translation quote.<\/strong><\/p>\n

This checklist does not certify that a course is usable, sellable, accessible, payable, or compliant in China. It only decides whether a controlled piece of adaptation work has a defensible starting line.<\/p>\n

Why a folder of course files is not a start signal<\/h2>\n

The word course<\/em> makes many different objects sound interchangeable. They are not. A lesson page, a quiz, a downloadable workbook, a live session, and a learner-facing interface can each carry different work and different decision owners.<\/p>\n

That distinction is visible in mainstream course tools. Teachable separates student-facing school translation from other product surfaces; its help documentation says automatic translation of student-facing web text does not apply to its iOS or Android apps.1<\/a><\/sup> Kajabi documents lesson and quiz import as separate course-object actions.2<\/a><\/sup> Neither source says anything about a China launch. Together, they offer a more modest but useful warning: \u201cwe have the videos and copy\u201d is not a complete description of what must be adapted.<\/p>\n

\n

Readiness is not \u201cwe know what we own.\u201d It is \u201cwe know what we are changing, who can approve it, and what must be tested before we make a promise.\u201d<\/strong><\/p>\n<\/blockquote>\n

The six-gate readiness check<\/h2>\n

Use this framework before assigning a full translation, rebuilding a course, or presenting a delivery route as decided. It is deliberately narrower than a market-validation plan: it decides whether a scoped adaptation workstream<\/em> may begin.<\/p>\n

Gate 1: State one learner action and one bounded outcome<\/h3>\n

Write the first action a learner must take and the outcome that action is meant to support. \u201cLocalize the AI course\u201d is not a usable scope. \u201cAdapt the first lesson so a learner can understand and complete one named prompt-writing exercise\u201d is.<\/p>\n

Record a success condition and a stop condition beside it. For example, the work may stop if the exercise depends on an unapproved tool substitution, or if the lesson’s promised outcome would have to change. These are planning conditions, not test results.<\/p>\n

Decision:<\/strong> If the team cannot choose a first learner action, mark the project HOLD \u2014 scope is still a slogan<\/strong>.<\/p>\n

Gate 2: Separate the objects from the learner-facing surfaces<\/h3>\n

List what is actually in the first scope: lesson pages, videos, quiz questions, downloadable files, live sessions, emails, app screens, support instructions, and any other relevant object. Then list which learner-facing surfaces will change: language, instructions, examples, screenshots, exercise steps, or support copy.<\/p>\n

This is where the Teachable and Kajabi references help. They do not prescribe a universal workflow; they demonstrate that a course platform can treat language surfaces and course objects as distinct operational things. A translated web page therefore cannot stand in for a review of every learning surface, and a copied lesson cannot stand in for a teaching redesign.1<\/a><\/sup>2<\/a><\/sup><\/p>\n

Decision:<\/strong> If an object or surface is unknown, it may be excluded from the first scope, but it may not be silently assumed to be covered.<\/p>\n

Gate 3: Declare the asset route before promising the asset<\/h3>\n

For each in-scope object, write the intended route: retain unchanged, adapt, replace, defer, or route-test. This is not yet a platform-selection exercise. It is a record of what the project is assuming.<\/p>\n

An illustrative example: a team might put recorded lessons in the first scope, defer a live office hour, and route-test a workbook before it is promised to learners. The decision is not that one format is better. It is that the initial scope should not contain an asset whose route is still an invisible question.<\/p>\n

Decision:<\/strong> If an essential asset has no stated route, mark it HOLD \u2014 route unknown<\/strong>. If it is non-essential, defer it rather than letting it delay every other decision.<\/p>\n

Gate 4: Put approval authority next to every meaningful change<\/h3>\n

The most expensive ambiguity is often not a technical one. It is the sentence, \u201cWe can probably change that example.\u201d<\/p>\n

For each proposed change, name the source rights holder or designated reviewer, the change they may approve, and the record that would prove approval. Examples and screenshots can carry teaching meaning; a quiz can change the assessment; a replacement tool can change the promised learner outcome. A general conversation or commercial interest is not a substitute for a scoped written approval.<\/p>\n

Decision:<\/strong> No written authority for a material change means HOLD \u2014 authorization gap<\/strong>. Do not translate first and ask permission after the changed version exists.<\/p>\n

Gate 5: Treat the dependency and terminology inventory as an input, not a verdict<\/h3>\n

The published Course Dependency and Terminology Inventory<\/a> is the companion record for source terms, teaching claims, dependencies, assets, and change authority. It answers: What are we dealing with, and what cannot drift?<\/em><\/p>\n

This checklist asks a different question: Does that record now support a start decision?<\/em> A filled inventory can still lead to HOLD. A glossary does not prove rights, a dependency list does not prove a workable route, and a proposed Chinese rendering does not prove that the teaching experience is ready.<\/p>\n

Decision:<\/strong> Link the current inventory version. If essential entries are still unclassified or have no accountable owner, mark HOLD \u2014 critical input incomplete<\/strong>.<\/p>\n

Gate 6: Write the test that turns readiness into evidence<\/h3>\n

Every unknown that matters needs a test card: what will be checked, by whom, on which date, in what region or account\/device conditions where relevant, and what outcome would stop the work.<\/p>\n

This is intentionally not a claim that a test has happened. It is the bridge between a planned adaptation and a controlled validation. For an end-to-end example, see OriBridge’s Access, Payment, and Delivery Test Script<\/a>. A readiness checklist may identify that a route needs testing; it cannot report the result before that test is recorded.<\/p>\n

Decision:<\/strong> If a critical unknown has no test owner, date, or stop condition, mark ESCALATE \u2014 an important uncertainty has no path to resolution<\/strong>.<\/p>\n

Put the decision on one page<\/h2>\n

The checklist is useful only if someone can read the record and make a call. Start a new sheet when the scope or a material route assumption changes. Keep the previous version as evidence instead of silently overwriting it.<\/p>\n

Use the seven fields below for every gate. Decision, evidence tier, version, owner, boundary, and status<\/strong> are part of the record, not optional notes.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n
field<\/th>\ndecision this field supports<\/th>\nevidence tier<\/th>\nversion<\/th>\nowner<\/th>\nboundary to record<\/th>\nstatus<\/th>\n<\/tr>\n<\/thead>\n
first learner action<\/td>\nwhat the first work package is allowed to change<\/td>\nD: recorded plan<\/td>\nsheet ID + date<\/td>\nscope owner<\/td>\nnamed action, bounded outcome, success and stop condition<\/td>\nGO \/ HOLD<\/td>\n<\/tr>\n
objects and surfaces<\/td>\nwhat is included and explicitly excluded<\/td>\nB\u2013D: official object rule, inventory, or hypothesis<\/td>\ninventory version<\/td>\ncontent owner<\/td>\nlesson, quiz, asset, live component, interface and support surface<\/td>\nREADY \/ INCOMPLETE<\/td>\n<\/tr>\n
asset route<\/td>\nwhether each promised object has a stated route<\/td>\nB\u2013D: first-party rule or pending route test<\/td>\nroute assumption version<\/td>\ndelivery owner<\/td>\nretain, adapt, replace, defer, or route-test; named context only<\/td>\nKNOWN \/ TEST \/ HOLD<\/td>\n<\/tr>\n
approval authority<\/td>\nwhether a material change may begin<\/td>\nA: scoped written approval<\/td>\napproval record ID\/date<\/td>\nrights holder or designated approver<\/td>\nchange type and the limit of the approval<\/td>\nAPPROVED \/ HOLD<\/td>\n<\/tr>\n
dependency input<\/td>\nwhether critical terms and dependencies have accountable treatment<\/td>\nA\u2013D: linked source record<\/td>\nH3-11 inventory version<\/td>\nproduct owner<\/td>\nunresolved critical entries and what the inventory cannot prove<\/td>\nREADY \/ HOLD<\/td>\n<\/tr>\n
validation plan<\/td>\nhow an important unknown will become evidence<\/td>\nC: dated plan, not a result<\/td>\ntest-card version<\/td>\nnamed test owner<\/td>\nregion, account\/device conditions where relevant, decision rule and stop rule<\/td>\nPLANNED \/ ESCALATE<\/td>\n<\/tr>\n
conclusion<\/td>\nwhether the bounded package can start<\/td>\nlowest tier among critical fields<\/td>\nsheet version<\/td>\ndecision owner<\/td>\none-line reason plus what GO does not mean<\/td>\nGO \/ HOLD \/ ESCALATE<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

The letters are working evidence tiers for this worksheet: A<\/strong> is scoped written authority or an approved source record; B<\/strong> is a current first-party rule for the named context; C<\/strong> is a controlled test record or a dated test plan clearly labelled as untested; D<\/strong> is an editor-recorded hypothesis or planning decision. A lower tier is not automatically bad. It tells the decision owner what remains assumed.<\/p>\n

Do not copy a row without its boundary. A platform note that cannot be re-opened today cannot support a current route decision. The approval row is even stricter: if the change is material and the record is not A-level written authority, the status is HOLD.<\/p>\n

The labels should be blunt:<\/p>\n