mirror of
https://github.com/aliasvault/aliasvault.git
synced 2026-05-19 13:57:18 -04:00
Update translation contributing docs (#1383)
This commit is contained in:
Leendert de Borst
committed by
Leendert de Borst
Leendert de Borst
parent
85e33a9fcd
commit
f7b66ed307
@@ -1,33 +1,15 @@
|
||||
---
|
||||
layout: default
|
||||
title: Translations
|
||||
title: Add new language
|
||||
parent: Development
|
||||
grand_parent: Miscellaneous
|
||||
nav_order: 3
|
||||
---
|
||||
|
||||
# Translations
|
||||
|
||||
AliasVault supports multiple languages across all applications. Currently supported languages:
|
||||
- English
|
||||
- Chinese (Simplified)
|
||||
- Dutch
|
||||
- Finnish
|
||||
- German
|
||||
- Hebrew
|
||||
- Italian
|
||||
- Polish
|
||||
- Portugese (Brazilian)
|
||||
- Russian
|
||||
- Ukrainian
|
||||
|
||||
---
|
||||
|
||||
## Adding a New Language
|
||||
|
||||
# Add new language
|
||||
To add a new language to AliasVault, follow these steps in order:
|
||||
|
||||
### Step 1: Configure Crowdin Integration
|
||||
## Step 1: Configure Crowdin Integration
|
||||
|
||||
1. **Update crowdin.yml**: Add the new language identifier to the `crowdin.yml` file in the root of the repository
|
||||
2. **Crowdin will automatically**:
|
||||
@@ -35,25 +17,25 @@ To add a new language to AliasVault, follow these steps in order:
|
||||
- Offer new content for translation in the Crowdin web interface
|
||||
- Create translation files for the new language
|
||||
|
||||
### Step 2: Web App (Blazor WASM)
|
||||
## Step 2: Web App (Blazor WASM)
|
||||
|
||||
1. **Add language to LanguageService**: Update `apps/server/AliasVault.Client/Services/LanguageService.cs` with the new language identifier
|
||||
2. **Translation files to create (optional, Crowdin should make a PR for this automatically)**:
|
||||
- `apps/server/AliasVault.Client/wwwroot/locales/{language-code}.json`
|
||||
- `apps/server/AliasVault.Client/Resources/{language-code}.resx` files
|
||||
|
||||
### Step 3: Browser Extension
|
||||
## Step 3: Browser Extension
|
||||
|
||||
1. **Add language identifier to config**: Update `/apps/browser-extension/src/utils/i18n/config.ts` and insert new language based on existing structure
|
||||
1. **Create language file (optional, Crowdin should make a PR for this automatically)**:
|
||||
- `apps/browser-extension/src/locales/{language-code}.json`
|
||||
|
||||
### Step 4: Mobile App - React Native
|
||||
## Step 4: Mobile App - React Native
|
||||
|
||||
1. **Add language identifier to config:** Update `/apps/mobile-app/i18n/index.ts` and insert new language based on existing structure
|
||||
2 **Create translation file (optional, Crowdin should make a PR for this automatically)**: `apps/mobile-app/i18n/locales/{language-code}.json`
|
||||
|
||||
### Step 5: Mobile App - iOS Native
|
||||
## Step 5: Mobile App - iOS Native
|
||||
|
||||
**Location**: `apps/mobile-app/ios/`
|
||||
|
||||
@@ -69,7 +51,7 @@ To add a new language to AliasVault, follow these steps in order:
|
||||
- `Autofill/{language-code}.lproj/Localizable.strings`
|
||||
- `VaultUI/{language-code}.lproj/Localizable.strings`
|
||||
|
||||
### Step 6: Mobile App - Android Native
|
||||
## Step 6: Mobile App - Android Native
|
||||
|
||||
**Location**: `apps/mobile-app/android/app/src/main/res/`
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
layout: default
|
||||
title: Development
|
||||
parent: Miscellaneous
|
||||
nav_order: 1
|
||||
nav_order: 99
|
||||
---
|
||||
|
||||
# Development Guide
|
||||
|
||||
127
docs/misc/dev/release/index.md
Normal file
127
docs/misc/dev/release/index.md
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
layout: default
|
||||
title: Release
|
||||
parent: Development
|
||||
nav_order: 99
|
||||
---
|
||||
|
||||
# Publish new release
|
||||
|
||||
Follow the steps in the checklist below to prepare a new release.
|
||||
|
||||
{: .toc }
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
---
|
||||
|
||||
# Release preparation checklist
|
||||
|
||||
## Bump versions
|
||||
All clients and server apps contain a version definition that needs to be updated with every release. This version is used for communication between components to ensure they are compatible with eachother. Versions are also used for official publication on the app stores.
|
||||
|
||||
For bumping the version for all projects in one go, you can use the interactive script located in:
|
||||
```bash
|
||||
./scripts/bump_version.sh
|
||||
```
|
||||
|
||||
> If you prefer to update versions manually instead of using the interactive script, see the [Manual versioning](manual-versioning) page for detailed steps.
|
||||
|
||||
## Write changelogs
|
||||
When a new version of the mobile apps and/or browser extensions is released, write changelogs and commit them to:
|
||||
- iOS app: `./fastlane/metadata/ios/en-US/changelogs/[versionCode].txt`.
|
||||
> Filename should equal the `versionCode` in build.gradle.
|
||||
- Android app: `./fastlane/metadata/android/en-US/changelogs/[versionCode].txt`.
|
||||
> Filename should equal the `versionCode` in build.gradle.
|
||||
- Browser extensions: `./fastlane/metadata/browser-extension/en-US/changelogs/[semver].txt`.
|
||||
> Filename should equal the semver of the release (e.g. `0.20.0`).
|
||||
|
||||
## Update documentation
|
||||
- [ ] Update /docs instructions for any relevant changes to functionality or self-host installaton process
|
||||
- [ ] Update README screenshots if applicable
|
||||
- [ ] Update README current/upcoming features
|
||||
|
||||
---
|
||||
|
||||
# Release flow
|
||||
Follow the steps below to publish a new release to the various channels.
|
||||
|
||||
## Create a new release on GitHub
|
||||
The creation of the new release tag will cause the `install.sh` script to see the new version via GitHub and prompt the user to update when `install.sh update` is run.
|
||||
|
||||
1. Create a new release on GitHub with a new tag in semver format, e.g. `0.12.0`.
|
||||
2. Add a description to the release and generate the changelog.
|
||||
3. Publish the release.
|
||||
|
||||
### Publish new Docker Images
|
||||
The creation of the new release tag will automatically trigger the GitHub Actions workflow `Publish Docker Images` which will build the docker images and push them to the GitHub Container Registry. After publishing, the images will then be available for the installation script to pull during the update. Do take note that this publish step may take up to 15 minutes to complete. Between the creation of the release tag and the completion of the publish step, the installation script will not be able to pull the new images (yet) and can throw errors, this is expected. After the publish is completed, users can update their self-hosted installation by following the [update guide](/installation/update)
|
||||
|
||||
#### To locally build and publish the all-in-one Docker image:
|
||||
GitHub Actions has had issues in the past with building the all-in-one Docker image for arm64 because of unknown timeouts. To locally build for both amd64 and arm64 and push manually, run the following:
|
||||
|
||||
**Docker Hub**
|
||||
```bash
|
||||
# Login to Docker Hub
|
||||
docker login
|
||||
|
||||
# Build and push all-in-one image
|
||||
# Note: replace 0.22.0 below with the actual tag of the version that you're building and pushing
|
||||
docker buildx build --platform linux/amd64,linux/arm64/v8 \
|
||||
-f dockerfiles/all-in-one/Dockerfile \
|
||||
-t aliasvault/aliasvault:0.22.0 \
|
||||
-t aliasvault/aliasvault:latest \
|
||||
--push .
|
||||
```
|
||||
|
||||
**Ghcr.io**
|
||||
```bash
|
||||
# Login to ghcr.io
|
||||
docker login ghcr.io
|
||||
|
||||
# Build and push all-in-one image
|
||||
# Note: replace 0.22.0 below with the actual tag of the version that you're building and pushing
|
||||
docker buildx build --platform linux/amd64,linux/arm64/v8 \
|
||||
-f dockerfiles/all-in-one/Dockerfile \
|
||||
-t ghcr.io/aliasvault/aliasvault:0.22.0 \
|
||||
-t ghcr.io/aliasvault/aliasvault:latest \
|
||||
--push .
|
||||
```
|
||||
|
||||
## Publish new browser extension version
|
||||
The GitHub Actions workflow `Browser Extension Build` will build the browser extension(s) and publish the archive to the GitHub Actions Artifacts page and also upload the archives to the release.
|
||||
|
||||
> Note: this step is only required if the browser extension has been updated.
|
||||
|
||||
1. Download the browser extension archives from the newly published release. Note: it can take a few minutes for the artifacts to be available after the release has been published.
|
||||
2. Upload the Chrome archive to the Chrome Web Store.
|
||||
3. Upload the Firefox archive (normal + sources) to the Firefox Add-ons page.
|
||||
4. Upload the Edge archive to the Microsoft Edge Add-ons page.
|
||||
5. Submit the Safari extension to Apple for review:
|
||||
1. Navigate to the `apps/browser-extension` directory.
|
||||
2. Build the safari extension locally via `npm run build:safari`, which will output the build files to `dist/safari-mv2`. **Note: it's important to always rebuild, as otherwise stale build files from a previous build might get included in the Safari binary by accident!**
|
||||
3. Open the `apps/browser-extension/safari-xcode/AliasVault/AliasVault.xcodeproj` project in Xcode and submit the extension via the "Archive" and then "Distribute App" option.
|
||||
|
||||
## Publish new Mobile App version
|
||||
1. Submit the iOS app to Apple for review:
|
||||
1. Open the `apps/mobile-app/ios/AliasVault.xcworkspace` project in Xcode and submit the extension via the "Archive" and then "Distribute App" option.
|
||||
2. Submit the Android app to Google Play Console for review:
|
||||
1. Run the gradle build in the `apps/mobile-app/android` folder:
|
||||
```bash
|
||||
./gradlew app:bundleRelease
|
||||
```
|
||||
2. The resulting .aab file will be available in the following location.
|
||||
```bash
|
||||
apps/mobile-ap/android/app/build/outputs/bundle/release
|
||||
```
|
||||
3. Take this file and upload it to the Google Play Console.
|
||||
|
||||
### F-Droid automatic build and publish
|
||||
Note: The AliasVault GitHub repo is connected to the F-Droid alternative Android App Store. When a new Git release is published, F-Droid will automatically pull the latest changes, read the Fastlane metadata to retrieve the changelog, and build the app itself. This process is fully automatic, and publishing can take 2-3 days.
|
||||
|
||||
The AliasVault Android app build is configured by the following file which is part of the official `fdroiddata` repo on GitLab:
|
||||
[https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/net.aliasvault.app.yml](https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/net.aliasvault.app.yml)
|
||||
|
||||
If any changes were made to the Android app build process or if any new third party (expo) packages have been installed, make sure it still
|
||||
works with the F-Droid build process. This can be tested either locally via `fdroid build`, or it can be done by creating a new test commit in
|
||||
a forked `fdroiddata` repo on GitLab and making the `net.aliasvault.app.yml` point to the latest main branch. This way you can test whether
|
||||
the build itself works properly with the latest version before actually publishing a new release.
|
||||
37
docs/misc/dev/release/manual-versioning.md
Normal file
37
docs/misc/dev/release/manual-versioning.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
layout: default
|
||||
title: Manual versioning
|
||||
parent: Release
|
||||
grand_parent: Development
|
||||
nav_order: 2
|
||||
---
|
||||
|
||||
# Manual Versioning Steps
|
||||
|
||||
Alternatively, you can do it manually by following these steps:
|
||||
|
||||
## Versioning client and server
|
||||
- [ ] Update ./apps/server/Shared/AliasVault.Shared.Core/AppInfo.cs and update major/minor/patch to the new version. This version will be shown in the client and admin app footer. This version should be equal to the git release tag.
|
||||
- [ ] Update ./apps/server/Shared/AliasVault.Shared.Core/AppInfo.cs with the minimum supported client versions.
|
||||
- Only required if new API output breaks earlier client versions and/or this version of the client/API will upgrade the client vault model to a new major version.
|
||||
- [ ] Update ./install.sh `@version` in header ONLY if the install script content has changed since the last release. This allows the install script to self-update when running the `./install.sh update` command on default installations.
|
||||
|
||||
## Versioning browser extensions
|
||||
- [ ] Update `./apps/browser-extension/wxt.config.ts` with the new version for the extension. This will be shown in the browser extension web stores. This version should be equal to the git release tag.
|
||||
- [ ] Update `./apps/browser-extension/safari-xcode/AliasVault/AliasVault.xcodeproj/project.pbxproj` and set the version in `MARKETING_VERSION` and increase the build number in `CURRENT_PROJECT_VERSION`. This is the version that will be shown in the Safari Browser Extension App Store.
|
||||
- [ ] Update `./apps/browser-extension/src/utils/AppInfo.ts` with the new version for the extension. This version should be equal to the git release tag.
|
||||
- [ ] Update `./apps/browser-extension/src/utils/AppInfo.ts` with the minimum supported server version (in case of required API breaking changes).
|
||||
- [ ] Update `./apps/browser-extension/src/utils/AppInfo.ts` with the minimum supported client vault version (in case of required client vault model changes).
|
||||
|
||||
## Versioning mobile apps
|
||||
- [ ] Update `./apps/mobile-app/app.json` with the new version for the mobile app. This version should be equal to the git release tag.
|
||||
- [ ] Update `./apps/mobile-app/utils/AppInfo.ts` with the new version for the mobile app. This version should be equal to the git release tag.
|
||||
- [ ] Update `./apps/mobile-app/utils/AppInfo.ts` with the minimum supported server version (in case of required API breaking changes).
|
||||
- [ ] Update `./apps/mobile-app/utils/AppInfo.ts` with the minimum supported client vault version (in case of required client vault model changes).
|
||||
- [ ] Update `./apps/mobile-app/ios/AliasVault.xcodeproj/project.pbxproj` and set the version in `MARKETING_VERSION` and increase the build number in `CURRENT_PROJECT_VERSION`. This is the version that will be shown in the iOS App Store.
|
||||
- [ ] Update `./apps/mobile-app/android/app/build.gradle` and set the version in `versionName` and increase the build number in `versionCode`.
|
||||
|
||||
## Install script (docker images)
|
||||
If docker containers have been added or removed:
|
||||
- [ ] Verify that `.github/workflows/release.yml` contains references to all docker images that need to be published.
|
||||
- [ ] Update `install.sh` and verify that the `images=()` array that takes care of pulling the images from the GitHub Container Registry is updated.
|
||||
Reference in New Issue
Block a user