Target project: Fedify. Blocked by an implementable draft of the translation metadata FEP, now drafted as FEP-22cd: Attributing translations (originally scoped in hackers-pub/hackerspub#401; discussion). Enables Hackers' Pub translation federation. The exact public API and terms remain pending the proposal.
Motivation
Applications publishing multilingual articles need to carry translator credit per language, relationships to source content, and the source revision a translation follows. ActivityStreams attribution and language-tagged title/body strings alone do not represent all of this information.
Fedify should expose the agreed representation through its vocabulary APIs so applications can read and write it without manipulating raw JSON-LD in each dispatcher. Hackers' Pub will be an initial consumer, but the library API should not depend on its database schema, organization roles, or notification system.
Scope and API design
Pin the FEP draft revision used for implementation and link it in documentation and tests. First audit the installed vocabulary definitions and generation tooling: reuse any types or properties already supported. Add the missing Schema.org mappings or proposal-specific terms only after their expanded IRIs and semantics are settled.
Follow the repository's current vocabulary generation conventions. Put definitions in the authoritative source rather than only modifying generated TypeScript. Include generated documentation and exports where the package requires them.
The API needs to express a language version, its contributor or contributors, its source relationship, and optional revision/freshness metadata as defined by the proposal. Use the library's existing conventions for singular/plural accessors, identifiers, embedded objects, and linked-object retrieval. Supporting one translator in a product UI must not force a single-value wire format if the FEP permits several.
Preserve the difference between an unknown source baseline and a known stale translation. Missing metadata must not imply that a translation is current. A deleted contributor must not cause a parsed human translation to become an automatic translation.
JSON-LD and compatibility
Provide context mappings that preserve the exact meaning chosen in the FEP. Test compact and expanded inputs, including terms expressed with full IRIs. Verify that the new data coexists with content, contentMap, nameMap, and attributedTo, without changing their existing behavior.
Adding this support must not alter the serialized form of existing objects that do not use it. Keep remote dereferencing within the library's existing fetch and trust policies. Translation metadata is not a new grant of authority to send updates, and parsing it must not silently trust embedded actor identities.
If the FEP uses linked language-version resources, add the vocabulary accessors needed to follow them. Treat any requirement for new dispatcher or routing APIs as an explicit design question instead of hiding it inside a vocabulary patch.
Documentation
Include examples of an Article with an original and human translation, an organization article with different translators for two languages, and a source update followed by a review acknowledgement. Explain how an application keeps publishing authority separate from credit and preserves one article's interaction identity.
Label draft vocabulary support according to Fedify's current policy. State the targeted proposal revision and compatibility limits. Do not claim that adding fields causes Mastodon or another peer to render translation credits. Do not generate a stable FEP identifier or promise a package version before those are assigned.
Acceptance criteria
Target project: Fedify. Blocked by an implementable draft of the translation metadata FEP, now drafted as FEP-22cd: Attributing translations (originally scoped in hackers-pub/hackerspub#401; discussion). Enables Hackers' Pub translation federation. The exact public API and terms remain pending the proposal.
Motivation
Applications publishing multilingual articles need to carry translator credit per language, relationships to source content, and the source revision a translation follows. ActivityStreams attribution and language-tagged title/body strings alone do not represent all of this information.
Fedify should expose the agreed representation through its vocabulary APIs so applications can read and write it without manipulating raw JSON-LD in each dispatcher. Hackers' Pub will be an initial consumer, but the library API should not depend on its database schema, organization roles, or notification system.
Scope and API design
Pin the FEP draft revision used for implementation and link it in documentation and tests. First audit the installed vocabulary definitions and generation tooling: reuse any types or properties already supported. Add the missing Schema.org mappings or proposal-specific terms only after their expanded IRIs and semantics are settled.
Follow the repository's current vocabulary generation conventions. Put definitions in the authoritative source rather than only modifying generated TypeScript. Include generated documentation and exports where the package requires them.
The API needs to express a language version, its contributor or contributors, its source relationship, and optional revision/freshness metadata as defined by the proposal. Use the library's existing conventions for singular/plural accessors, identifiers, embedded objects, and linked-object retrieval. Supporting one translator in a product UI must not force a single-value wire format if the FEP permits several.
Preserve the difference between an unknown source baseline and a known stale translation. Missing metadata must not imply that a translation is current. A deleted contributor must not cause a parsed human translation to become an automatic translation.
JSON-LD and compatibility
Provide context mappings that preserve the exact meaning chosen in the FEP. Test compact and expanded inputs, including terms expressed with full IRIs. Verify that the new data coexists with
content,contentMap,nameMap, andattributedTo, without changing their existing behavior.Adding this support must not alter the serialized form of existing objects that do not use it. Keep remote dereferencing within the library's existing fetch and trust policies. Translation metadata is not a new grant of authority to send updates, and parsing it must not silently trust embedded actor identities.
If the FEP uses linked language-version resources, add the vocabulary accessors needed to follow them. Treat any requirement for new dispatcher or routing APIs as an explicit design question instead of hiding it inside a vocabulary patch.
Documentation
Include examples of an
Articlewith an original and human translation, an organization article with different translators for two languages, and a source update followed by a review acknowledgement. Explain how an application keeps publishing authority separate from credit and preserves one article's interaction identity.Label draft vocabulary support according to Fedify's current policy. State the targeted proposal revision and compatibility limits. Do not claim that adding fields causes Mastodon or another peer to render translation credits. Do not generate a stable FEP identifier or promise a package version before those are assigned.
Acceptance criteria