Ensure localization of Collector component tables is preserved during regeneration

[vitorvasc]

Context

The Collector components pages were introduced in #8001 and are generated via automation, which scrapes Collector metadata and regenerates the tables in these pages after each Collector release.

As of #8464, we already have translations for those pages. The translated table headings are surrounded by the <!-- BEGIN GENERATED: [...] --> generation block. A subsequent regeneration could potentially overwrite or affect the localized content.

See the discussion in https://github.com/open-telemetry/opentelemetry.io/pull/8464/changes#r2613525033.

Proposal

Ensure the generated content only outputs the table rows (data) within the generation markers so that future updates to that content won't affect the localized content.

• [ ] Move Collector components data into the ./data directory, aligning it with other files such as registry entries, community members, etc.
• [ ] ...

/cc @jaydeluca

[jaydeluca]

Ensure the generated content only outputs the table rows (data) within the generation markers so that future updates to that content won't affect the localized content.

👍 I will take care of this on the collector-watcher side if you want to handle moving the markers around on the pages themselves

Move Collector components data into the ./data directory, aligning it with other files such as registry entries, community members, etc.

Let me know how I can help with this piece

[vitorvasc]

👍 I will take care of this on the collector-watcher side if you want to handle moving the markers around on the pages themselves

@jaydeluca I just tested moving the markers in my local envrionment, but it doesn't seem to work well. It breaks the Markdown syntax and the table fails to render. 😓

Alternatively, I've been looking at how the Community Members page is rendered. Its data is stored in a .yaml file — see data/community/members.yaml — which then passes through the layouts/_shortcodes/community/members-list.html shortcode to be rendered in content/en/community/members.md.

What do you think of this approach? Would it be possible to handle the Collector components via a .yaml file, similar to how we handle community members?

Also, if you have any other ideas, feel free to share them or try them out in a new branch too. 😄

[jaydeluca]

What do you think of this approach? Would it be possible to handle the Collector components via a .yaml file, similar to how we handle community members?

great idea, I think this makes a lot of sense! I'll give it a try. How will localization come into play here? will there just be a different shortcode per language?