[LFX] Explore localization team status visibility reporting

[apullo777]

What would you like to be added?

I would like to explore a lightweight reporting helper for localization team status visibility.

The goal is to provide a simple way to see, at a glance, which localized files are most likely to need review based on better outdated-content signals, so localization maintainers can prioritize update work more effectively.

Rather than centering this work on Git recency alone, I want to explore a visibility/reporting layer that can eventually consume stronger signals from the content-based outdated detection work in #54896.

Possible initial prototype scope:

• accept a target localization language (for example ko)
• compare files that exist in both content/en/ and content/ko/
• summarize files that are most likely to deserve review based on available outdated-content signals
• output a ranked or grouped summary to help maintainers identify which files may deserve attention first
• keep the implementation lightweight and easy to maintain

This issue is part of the broader LFX localization workflow effort: #54075

Why is this needed?

Today, localization contributors can inspect specific files or directories with existing tools such as scripts/lsync.sh, which is useful when working on a known target file.

However, there is still a separate workflow need: team-level visibility.

Examples of visibility questions include:

• Which files in our localization set are most likely to need review?
• Which areas should we review first in the next update cycle?
• How can maintainers quickly get a rough status snapshot for planning or reporting?

A lightweight visibility-oriented helper could support these workflows, especially if it is built on top of better outdated-content signals rather than relying only on timestamps or commit chronology.

This issue also builds on earlier exploration of localization reporting in #45844, but the goal here is not to continue with a Git-recency-based direction as the main approach. Instead, the intention is to explore a smaller visibility helper that can eventually align with the stronger content-based outdated detection work being explored in #54896.

In particular, this direction is intended to:

• keep the scope smaller and easier to review
• avoid claiming semantic or content-level freshness detection beyond what the underlying signals can support
• complement existing workflows such as scripts/lsync.sh, rather than replace them
• allow the reporting/visibility layer to evolve separately from the detector implementation details

This work is also separate from content-based outdated detection efforts. More advanced detection approaches can continue in their own workstream, while this issue focuses on a smaller visibility/reporting layer.

Scope

Initial exploration scope:

• single-language reporting per run
• visibility/reporting based on available outdated-content signals
• ranked or grouped text output suitable for local maintainer use
• minimal implementation complexity
• easy to test and review

Non-goals

This issue is not intended to:

• define the full outdated-content detection algorithm itself
• replace existing scripts
• introduce AI-, embedding-, or semantic-based comparison directly in this reporting layer
• enforce synchronization rules
• define a universal workflow for all localization teams

/area localization


[k8s-ci-robot]

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[apullo777]

Quick update after mentor discussion:

We’ve clarified that Git-based recency reporting is not the main goal for this LFX work. Instead, we plan to continue focusing on the content-based outdated detection approach in #54896, and then explore any future reporting/visibility tooling on top of that stronger signal. I’ll update this issue description so it no longer frames the work as Git-based.

[seokho-son]

@apullo777 Thanks for the update!

I agree with focusing on the main goal of this issue. It would be great to propose tools that can provide additional support to localization teams, especially in areas that were previously missed or difficult to address, and to prepare a demonstration as well.

Rather than trying to introduce something that all localization teams must adopt or that would require them to change their workflows abruptly, I think we should aim to establish best practices that can be commonly used across multiple localization teams. This would allow existing teams to gradually reference and adopt them in a more natural way.

[seokho-son]

FYI, while the goal of this issue is reasonable, I think it makes sense to mark this as "triage/accepted" after we’ve created an initial draft and validated its effectiveness.

[wonyongg]

@apullo777
I think this is definitely worth discussing.

I’m looking forward to seeing your ideas for the visibility tool
really appreciate you taking this forward🙏