Weblate Component Aliases: Share Translations, Keep Repositories Separate

Problem: several products reuse the same interface text, but each product ships from its own repository and release cycle. Copying source strings into every Weblate component duplicates translation work and makes it easy for one product to ship "Sign in" while another ships "Log in."

Takeaway: use a Weblate component alias so one component reuses another component's translations without duplicating source strings. The alias keeps its own access control, quality checks, screenshots, and version-control repository; only the translation relationship is shared.

Requirements

• Source and alias components must be in the same Weblate project. Cross-project aliases are not a supported substitute for translation memory.
• String keys and file formats should match closely enough for Weblate to map strings. Different formats increase the chance of missing or mismatched strings.
• You need project or component administration rights to create or change an alias. API verification needs a service-account token with read access to the components endpoint.
• Confirm aliasing is supported and behaves as expected in your deployed Weblate version; propagation timing and field names have changed between releases.

Smallest suitable design

Use one source component and one alias component per shared string set. Example: a payments project has source component checkout-ui in repository https://git.example.com/payments/checkout-ui.git and alias component checkout-ui-mobile in repository https://git.example.com/payments/checkout-ui-mobile.git. Both components live in project payments. The alias component's settings point to checkout-ui as the component to alias.

In the Weblate UI: open the alias component, go to Component settings, find Alias of component, select the source component, and save. Do not copy the source repository into the alias component; the repositories remain independent and Weblate does not merge branches or history.

Trust and data boundaries

Configuration and API verification

Run API calls from a host with network access to Weblate. Protect the token: export it in the current shell only and do not commit it to version control.

WEBLATE_BASE_URL=https://weblate.example.com
API_TOKEN=your-service-account-token
PROJECT=payments
SOURCE_SLUG=checkout-ui
ALIAS_SLUG=checkout-ui-mobile

curl -s -H "Authorization: Token $API_TOKEN" $WEBLATE_BASE_URL/api/components/$PROJECT/$ALIAS_SLUG/

Required permission: read access for the token; administration rights to change the alias. Expected check: the response is HTTP 200 and the alias or aliasof field identifies checkout-ui; it is not null or missing. Risk: an incorrect slug returns HTTP 404 or aliases the wrong component, which silently shares the wrong translations.

UI check after configuration: open the alias component, select a language, and confirm source strings and existing source translations appear without a separate translation step in the alias. Then change one approved translation in the source component and confirm the same translation is available in the alias. If it does not appear, run the component update or synchronization for your Weblate version and check Weblate logs; propagation is not guaranteed to be instant.

Failure modes

• Deleting or renaming the source component can break every alias that references it, sometimes without a clear deletion warning. Before deleting a source component, list project components and find any component whose alias field references the source.
• New source strings do not automatically reach aliases unless templates and alias settings are aligned. Treat new strings as a change that requires verification on the alias.
• Shared translations can blur per-product review history and attribution, which complicates audits when several products reuse the same text.
• Semantic mismatch: do not alias unrelated domains, such as an admin console and a marketing site, because one translation may be wrong for the other context.

Operational checks and rollback

• After any source-component change, check the alias component for new, missing, or fuzzy strings before the next product release.
• Review Weblate logs after alias configuration, source deletion, or repository updates.
• Confirm alias-specific checks and screenshots still pass; sharing translations does not share check results.

Rollback: because creating or changing an alias changes Weblate configuration state, you can reverse it by editing the alias component and clearing Alias of component. Review alias-specific translations and checks first; clearing the alias removes the shared-translation link but does not automatically delete the alias component or its repository.

When the design should change

Move away from aliases when components are in different Weblate projects, when the same English string needs different translations per product, when per-product translation history must be independent, or when string formats diverge. In those cases use separate components with translation memory and glossaries instead of an alias.

Practical result check: after setup, the API component detail for the alias shows a non-null reference to the intended source component, and the UI alias component displays source translations without a separate translation workflow. If either condition fails, do not promote the change; fix the alias configuration or fall back to separate components.