Standardize Translation Process w/ Documentation and Translation Tool
Epic: https://source.puri.sm/Librem5/use-cases/issues/62
Issue: With only three language translations, there is already a decent amount of variety within the copyright header comments:
German:
# German translations for phosh package.
# Copyright (C) 2018 THE phosh'S COPYRIGHT HOLDER
# This file is distributed under the same license as the phosh package.
# Automatically generated, 2018.
#Spanish:
# Spanish translation for phosh package.
# Copyright (C) 2018 THE phosh'S COPYRIGHT HOLDER
# This file is distributed under the same license as the phosh package.
# Alberto Fanjul <albfan@gnome.org>, 2018.
#Italian:
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the phosh package.
# FIRST AUTHOR <ant.pandolfo@gmail.com>, 2018.
#For example, the Italian header is missing the "[...] translations for phosh package" and has a 'FIRST AUTHOR' line whereas the Spanish .po doesn't have this text and the German .po has 'Automatically generated'. There should be a standardized header across translations files.
Proposed Solutions: Create a documented/standardized process for contributing translations:
Short Term: @guido.gunther should probably write a guide on how to contribute a translation in either the README or Wiki so that the same process is more likely to be followed resulting in similar copyright headers and making it easier for people not familiar with translating .po files resulting in more contributions
Long Term: Purism should setup a translation web service instance of Weblate, Pootle, or something similar which in turn provides numerous benefits. Not all privacy lovers are necessarily familiar with cloning, committing, and PR'ing and using such an instance eliminates most of the hurdles and allows them to focus on just translating strings. It also provides easier management of translations; Purism can easily see how many x of y strings are translated, and adding a new string in the 'master' copy is automatically reflected in the .po files. There are also other features that help make sure terminology is similar across strings, etc. While the benefits may not be immediate now given how few strings there are, it's easier to set this up now while there are only three languages with a few strings than later on with many languages with many strings.