Custom website development: the client wants a Japanese version, but no one on our team speaks Japanese—can we take the job?

This kind of request can be taken, but the way you take it on needs to change: the development side is responsible for the language structure and launch, while who provides the target-language content and who signs off on it must be settled before the quote. Based on enterprise project delivery experience in 2026, language versions usually get stuck not because of development capability, but because no one is willing to take responsibility for the translation. If the client has no Japanese-speaking staff and does not plan to commission translation, a common approach is to start with an English-only version and reserve language subdirectories, then add languages once there is a clear content owner.

When no one speaks Japanese, the bottleneck is not development—it is the content owner

A multilingual site breaks down into three things: structure, translation, and review. Structure falls within development scope, including an independently accessible URL for each language (commonly subdirectories or subdomains such as /en/ and /ja/), hreflang annotations between languages, staying on the corresponding page after switching languages, and form notifications carrying the language source. Translation and review fall within content scope and need to be done by people who understand the target language and also know the product; the development side usually does not have this role.

Of the three, structure can be built well once and reused long term; translation and review are ongoing. This is also where late-project disputes commonly arise: three months after launch, the product is updated—who updates the Japanese pages? If this is not made clear at contract signing, in most cases it turns into ad hoc machine translation, and page quality declines accordingly.

• Development owns: language directory planning, multilingual template support, hreflang annotations, switching logic, and language identifiers for forms and notifications.
• Client or translation vendor owns: body copy translation, approved translations for product names and proper nouns, terms and privacy policy, and final translation sign-off.
• Both sides agree up front on: update frequency, delivery cadence for each update, and who is responsible for back-end entry.

Run through four questions before accepting; if they cannot be answered, do not schedule it yet

1. Who writes and who reviews the target-language content? Having in-house staff for that language or a regular translation vendor both count as answers; 'we'll figure it out later' does not.
2. How much content needs translating? Count pages first: doing only a homepage plus contact page is not on the same scale as a product library with hundreds of detail pages.
3. How often will it be updated? A product change every six months versus weekly new releases makes a clear difference in ongoing maintenance effort.
4. Who signs off on the translation? There needs to be a person responsible for content quality who can be part of the conversation when issues arise.

If any one of the four questions has no answer, the safer approach is to remove that language from the current schedule, deliver first as a single-language or English version, and leave the language structure in place. If you take it on regardless, a common cost is that after launch the client is unhappy with the translation and both sides believe the other should be responsible.

English first or the target smaller language first: a comparison you can check against

Base the decision first on where existing inquiries come from, then on the content resources you can invest. The following reflects typical project experience ranges in 2026 and should not be treated as fixed pricing.

• Coverage: An English version has a broader potential audience, and one set of content can serve multiple markets; a smaller-language version has narrower coverage but is more targeted.
• Translation cost: English translators and writers are widely available, and per-word pricing is commonly lower; for smaller languages, supply is limited, and the cost for the same word count is commonly 1–3x higher (experience range).
• Review resources: It is relatively easier to find reviewers for English content; reviewers for smaller languages are harder to find, and scheduling takes longer.
• Search competition: Core English keywords are highly competitive, so a new site is unlikely to break through in the short term; long-tail keywords in smaller languages are relatively less competitive, but this still depends on the industry.
• Maintenance effort: Each additional language commonly increases content synchronization and review workload by 20%–50% (experience range), and it is a long-term commitment.

An actionable judgment is: if there have been steady inquiries in a certain language over the past six months, you can clearly describe the target market, and you can find reviewers, then do that language first; if it is only a feeling that there may be overseas opportunities, start with an English version to test the waters, while reserving the language subdirectory and hreflang framework so that adding languages later does not require rebuilding links.

On delivery: the cost of not reserving structure once

The constraints are usually like this: the budget and timeline are only enough for one version first, and the client clearly says the Japanese version will come later. Before entering design, we write the language directory, hreflang framework, and content owner into the delivery statement; even if the current scope is only Chinese plus English, we reserve the structure as /en/ and /ja/. This way, when a new language is added later, it commonly can go live in 1–3 weeks (experience range), with the main work being content preparation and checks.

Another scenario is more costly: if languages were implemented early with parameters or pure front-end switching, adding a language later requires rearranging URLs and rebuilding redirects, commonly 3–10 business days of rework (experience range), and the performance of already indexed pages may also fluctuate. This kind of rework is mostly not a technical problem; it comes from not asking one question at the start: who owns the content?

Applicable and non-applicable boundaries

When it fits: there are steady non-Chinese inquiries, the target market is clear, reviewers can be found, and the product or service needs its descriptions adjusted to local habits. In this case, multilingual versions can support actual lead generation, and the investment is easier to calculate.

When to pause or skip it: inquiries basically come from the Chinese-speaking market; no one can continuously maintain non-Chinese content; the budget only covers machine translation and there is no plan to proofread; deals mainly rely on offline relationships. Under these conditions, starting with key English pages, or using browser translation to assist communication, is usually enough. Remember one boundary: a multilingual site is ongoing content work, not a one-time translation delivery.

FAQ

If the client provides the translation, do we still need to check it?

Yes. At minimum, verify that translations match the corresponding pages, product names are consistent, and language switching lands on the right page. Content quality is the client's responsibility; structural misalignment is a delivery issue and should be fixed by development.

Can machine translation go live first to get by for a while?

It is not recommended to make it public directly. Machine translation can be used as placeholder content and temporarily kept out of search engine indexing; pages such as product names, terms of service, and privacy policy especially need human review, otherwise they can easily cause misunderstandings and loss of trust.

If we only do an English version now, will adding Japanese later require redoing everything?

As long as URLs are planned as language subdirectories and the hreflang structure is reserved up front, adding a language later usually does not require rebuilding links; it commonly goes live in 1–3 weeks (experience range), with most time spent on content preparation and verification.

What counts as a qualified multilingual version?

Look at four points: whether each language can be accessed and indexed independently, whether key pages are properly translated, whether switching languages stays on the corresponding page, and whether form notifications include the language source. These four points say more about quality than the number of languages.

If no one can continuously update the smaller-language content, is there an alternative?

You can keep only three core layers—homepage, product list, and contact page—to reduce the pages that need synchronization; agree on a quarterly or semi-annual update cadence and write down who enters content into the back end.

If stable non-Chinese inquiry sources have already appeared in the inquiry back end, in 2026 you can first plan one language subdirectory on the existing site, complete the homepage, product details, contact page, and privacy policy, and then decide whether to add a second language. If non-Chinese inquiries are very few and there are no reviewers, making the existing site's content and conversion path solid first is usually more practical than rolling out multiple languages.