Project owners define what platforms exists and what plugins should be used for each platform.
Pros:
we can lint platform mismatches across an inlang project e.g. the platform "android2" is used in the function registry but doesn't exist in the platform registry
if a platform should start using a different plugin, only the platform registry needs to be adjusted
The main question for the registry is who owns it. Is it part of the Ecosystem itself via the SDK or is it App-specific, or a mix.
The project owns the registry.
As an app, you have to comply. E.g. the project defines a plural function with input: X, output: Y, it's paraglide's (and other exporters/i18n libs) job now to provide this function during the runtime.
For the registry, I propose a property implementation or something that is a web/js implementation of the function that can be used to execute the function in inlang apps e.g. fink.
Okay, wuuuuuups here might be the answer for paraglide and on how to ensure consitency across different i18n libraries. The project owns the implementation with source code stored in the project itself (see implementation: Record<Platform, File> prop):
It seems like we need a registry for platforms in a project too.
Expected user flow:
Project owners define what platforms exists and what plugins should be used for each platform.
Pros:
Context:
@samuel.stroschein said in MESDK-97: