Scoping a Localization System Around the Actual Users
How scoping a localization system around real users, maintenance costs, and workflow design reduced complexity and created a more sustainable engineering solution.
I almost translated my entire portfolio into Japanese.
I’m glad I didn’t.
The obvious solution was full localization. If I was applying for game engineering roles in Japan, why not translate everything?
The more interesting question was whether that would actually solve the problem.
What started as a small portfolio feature became an exercise in scoping, audience analysis, and reducing future maintenance.
The lesson had very little to do with localization.
It had everything to do with engineering scope.
The real problem
Engineering is often less about building the maximum solution and more about building the smallest solution that solves the actual problem.
I started treating the portfolio as a product with a specific audience rather than a personal website.
The people I expected to visit it fell into three groups:
- recruiters,
- hiring managers,
- technical leads and senior engineers.
Those groups do not need the same information.
Recruiters and hiring managers usually need to evaluate candidate fit quickly: language ability, work authorization, location, role alignment, and overall positioning. For that audience, having key information available in Japanese reduces the effort required to decide whether I am worth moving forward with.
Technical interviewers are different. Some are comfortable reading English technical content, while others prefer Japanese. Rather than assuming English proficiency, I focused on accurate signaling.
My portfolio represents someone who works professionally in English and communicates in conversational Japanese.
Fully translating every project article would imply a level of Japanese technical communication that I do not currently have. It would also create a significant maintenance burden.
The problem became finding the minimum amount of localization that meaningfully reduced friction without creating misleading signals or unnecessary translation work.
Defining the localization boundary
Once that became clear, the implementation became much simpler.
I localized:
- navigation and UI controls,
- introductory content,
- section headers,
- subtitles,
- key positioning information.
The project pages and engineering articles remained in English.
This created a portfolio that was easier to navigate in Japanese while keeping the technical work representative of my actual working environment.
More importantly, it kept the localization surface area intentionally small.
Designing for future maintenance
The next decision was architectural rather than visual.
I structured the localization system around stable localization IDs that separated translated strings from the application code.
The technology itself was not the interesting part.
The important question was how quickly I could update the portfolio later.
Copy changes.
Sections get reorganized.
New content gets added.
A localization system that is easy to implement once can still become expensive to maintain.
I automated the repetitive parts of the workflow, but the real goal was not automation.
It was reducing future maintenance.
Optimizing the workflow
The most useful part of the project was not the translation pipeline.
It was the debugging workflow.
One lesson I’ve carried over from game development is that the slow part is often not making a change.
The slow part is finding where the change needs to be made.
I built a debug mode that visually highlighted localized elements and displayed the localization ID associated with each string.
Instead of searching through components and translation files manually, I could immediately identify:
- which string was being rendered,
- which localization key it used,
- whether the translation belonged in the correct context.
That turned localization into a fast feedback loop.
Edit a translation.
Refresh the page.
Verify the result.
Move on.
The tool was simple, but it significantly reduced the cost of iteration.
The same pattern I’ve seen in game development
While working on this project, I realized I was solving the same problem I’ve encountered repeatedly in gameplay engineering.
Not localization.
Future iteration.
The entire localization system was implemented in a single day because the problem had already been constrained.
The workflow was straightforward:
- identify the minimum localization surface,
- implement the localization framework,
- automate repetitive work,
- validate layouts,
- review translations,
- iterate on newly discovered UI elements.
Several rounds of testing revealed additional interface elements that benefited from translation, but because the system was already structured around stable IDs and quick verification, expanding the scope remained inexpensive.
That is the same principle behind many gameplay tools and production workflows.
A small amount of upfront structure can make future iteration dramatically cheaper.
Trade-offs and constraints
This was intentionally not a comprehensive internationalization system.
Machine translation was sufficient for UI and introductory content, but I manually reviewed translations involving technical terminology, professional positioning, and Japanese phrasing that could create the wrong impression.
I also accepted that some content would remain English permanently.
The trade-off was deliberate.
A fully localized portfolio would improve completeness.
A selectively localized portfolio improved maintainability, development speed, and honest representation.
Given the audience and my career goals, that was the better engineering decision.
What changed
The visible result was a language toggle.
The more important result was a workflow that made future localization inexpensive.
The portfolio now supports quick copy updates, visual verification, and incremental expansion without requiring every new article to be translated.
The project reinforced a pattern that has become increasingly important to me.
The most valuable engineering work often comes from reducing the cost of future changes, not from increasing technical sophistication.
Looking back
The interesting part of this project was not the localization framework.
It was the decision process.
I started with a feature request.
I identified the users.
I reduced the problem to the smallest useful scope.
Then I built a workflow that made future changes fast.
That is the same approach I try to bring to gameplay systems, designer tooling, and production workflows.
The implementation was small.
The engineering judgment was deciding what not to build.
Final thoughts
Localization was never the bottleneck.
The bottleneck was understanding who the portfolio was for.
Once that became clear, the architecture became smaller, the workflow became faster, and the maintenance burden became manageable.
Sometimes the best engineering decision is not building a bigger system.
It is designing a smaller one that can evolve cleanly over time.
What’s Next?
If this way of thinking about scope, workflows, and engineering decisions resonates, feel free to explore more of my work and the projects I’ve worked on.
Based in Japan • Available for technical gameplay implementation and cross-disciplinary development.