✨ Help Wanted! | Add Weblate i18n Support #1106

New Issue

jonah · 2019-08-06T05:22:32Z

jonah commented

2019-08-06 05:22:32 +00:00

Checklist

Homepage
Providers
- Avoid US Services
- Cloud Storage
- DNS
- Email
- Hosting
- Pastebin
- Search
- Social Networks
- Social News Aggregators
- VPN
Browser
- Fingerprint
- Browser Addons (#1138)
- Tweaks
- Recommendation
- WebRTC Section
Software
- Calendar/Contacts Sync
- Notebook
- Email Alternatives
- Email Clients
- File Encryption
- File Sharing
- Password Manager
- Productivity
- Real-Time Communication
  - IM
  - VoIP
  - Team Chat
- File Sync
- Self-Contained Notebooks
- Self-Hosted Cloud
OS
- Android Add-ons
- Windows 10 (In progress: cb2ae143ed)
- Live CD (#1163)
- Mobile (#1163)
- PC (#1163)
- Router (#1163)
Services Page (#1138)
Donate
Contact
Navbar
Footer (#1138)

Description

Alright. So it turns out if we use jekyll-multiple-languages-plugin and throw every single string on the site into /_i18n/en.yml we can then use our Weblate install to translate the site much easier.

The problem of course, is moving all the strings manually 😅

So that's going to be my project for now. As of df38bc4 I have successfully moved... the index page to en.yml, which took about an hour 🙄

If anyone wants to help me out with this (which I would greatly appreciate), I'm doing this work in the i18n branch of this repo. If you aren't an org member you can create Pull Requests to that branch (as opposed to master), by selecting i18n instead as the base branch in your pull request:

What needs to be done

Every English text string in every (HTML and Markdown) file needs to be moved to a key in en.yml. For example, lets look this line in _includes/sections/privacy-resources.html:

...
<h1 id="resources" class="anchor"><a href="#resources"><i class="fas fa-link anchor-icon"></i></a> More Privacy Resources</h1>
...

That is of course the More Privacy Resources header on the homepage. What I've done is taken the English text out of that line, and placed it en.yml, like so:

...
privacy_resources:
  header: "More Privacy Resources"
  ...

Then, back in the HTML file, I replaced the English text with {% t privacy_resources.header %} (which is a Jekyll tag saying to translate the string privacy_resources.header (from the lines above). Like so:

<h1 id="resources" class="anchor"><a href="#resources"><i class="fas fa-link anchor-icon"></i></a> {% t privacy_resources.header %}</h1>

Which really isn't that hard! It's simply time consuming to copy/paste everything into this file.

Extra note about translating `{% include card.html`s

Okay, so there is one slightly more complicated bit. You can't add the {% t tags inside the {% include` tags. For example, you cannot do this:

{% include cardv2.html
title="{% t browser_addons.privacy_badger_title %}"
description="{% t browser_addons.privacy_description %}"
...

You must instead use some fancy {% capture tags, like so:

{%- capture title1 -%}{% t browser_addons.privacy_badger_title %}{%- endcapture -%}
{%- capture descr1 -%}{% t browser_addons.privacy_description %}{%- endcapture -%}

{% include cardv2.html
title=title1
description=descr1
...

It isn't too complicated, just some extra steps. Look at what I did in resources.html for a more complete example.

`en.yml`

You can see how I've formatted this file already, but basically it should be like:

PAGE:
  KEY: "String"

Where "Page" is the section being translated, Key is a brief description, and "String" is the English text. At the top there is also a "Global" section, for strings that are reused a bunch on different pages:

global:
  further_reading: "Further Reading"

Pretty much everything needs to go into this file, and then this file will automatically be used as the base in Weblate upon which all translations will be based on (which will be far easier).

## Checklist - [x] Homepage - [ ] Providers - [ ] Avoid US Services - [ ] Cloud Storage - [ ] DNS - [ ] Email - [ ] Hosting - [ ] Pastebin - [ ] Search - [ ] Social Networks - [ ] Social News Aggregators - [ ] VPN - [ ] Browser - [ ] Fingerprint - [x] Browser Addons (#1138) - [ ] Tweaks - [ ] Recommendation - [ ] WebRTC Section - [ ] Software - [ ] Calendar/Contacts Sync - [ ] Notebook - [ ] Email Alternatives - [ ] Email Clients - [ ] File Encryption - [ ] File Sharing - [ ] Password Manager - [ ] Productivity - [ ] Real-Time Communication - [ ] IM - [ ] VoIP - [ ] Team Chat - [ ] File Sync - [ ] Self-Contained Notebooks - [ ] Self-Hosted Cloud - [ ] OS - [x] Android Add-ons - [ ] Windows 10 (In progress: https://github.com/privacytoolsIO/privacytools.io/commit/cb2ae143ed66239ac3dc54cb4b2708b84fdc1f8e) - [x] Live CD (#1163) - [x] Mobile (#1163) - [x] PC (#1163) - [x] Router (#1163) - [x] [Services](https://www.privacytools.io/services/) Page (#1138) - [x] Donate - [x] [Contact](https://www.privacytools.io/contact/) - [x] Navbar - [x] Footer (#1138) ## Description Alright. So it turns out if we use [jekyll-multiple-languages-plugin](https://github.com/kurtsson/jekyll-multiple-languages-plugin) and throw *every single string on the site* into `/_i18n/en.yml` we can then use [our Weblate install](https://weblate.nablahost.com/projects/privacytoolsio/) to translate the site much easier. The problem of course, is moving all the strings manually 😅 So that's going to be my project for now. As of df38bc4 I have successfully moved... the index page to `en.yml`, which took about an hour 🙄 If anyone wants to help me out with this (which I would greatly appreciate), I'm doing this work in the [`i18n` branch](https://github.com/privacytoolsIO/privacytools.io/tree/i18n) of this repo. If you aren't an org member you can create Pull Requests to that branch (as opposed to master), by selecting i18n instead as the base branch in your pull request: <img width="234" alt="image" src="https://user-images.githubusercontent.com/3637842/62512624-55b41a00-b7de-11e9-95c1-5d7c3136098b.png"> ## What needs to be done Every English text string in every (HTML and Markdown) file needs to be moved to a key in `en.yml`. For example, lets look this line in `_includes/sections/privacy-resources.html`: ``` ... <h1 id="resources" class="anchor"><a href="#resources"><i class="fas fa-link anchor-icon"></i></a> More Privacy Resources</h1> ... ``` That is of course the **More Privacy Resources** header on the homepage. What I've done is taken the English text out of that line, and placed it `en.yml`, like so: ``` ... privacy_resources: header: "More Privacy Resources" ... ``` *Then*, back in the HTML file, I replaced the English text with `{% t privacy_resources.header %}` (which is a Jekyll tag saying to `t`ranslate the string `privacy_resources.header` (from the lines above). Like so: ``` <h1 id="resources" class="anchor"><a href="#resources"><i class="fas fa-link anchor-icon"></i></a> {% t privacy_resources.header %}</h1> ``` Which really isn't that hard! It's simply time consuming to copy/paste everything into this file. ### Extra note about translating `{% include card.html`s Okay, so there is one slightly more complicated bit. You can't add the `{% t` tags inside the {% include` tags. For example, you **cannot** do this: ``` {% include cardv2.html title="{% t browser_addons.privacy_badger_title %}" description="{% t browser_addons.privacy_description %}" ... ``` You must instead use some fancy `{% capture` tags, like so: ``` {%- capture title1 -%}{% t browser_addons.privacy_badger_title %}{%- endcapture -%} {%- capture descr1 -%}{% t browser_addons.privacy_description %}{%- endcapture -%} {% include cardv2.html title=title1 description=descr1 ... ``` It isn't too complicated, just some extra steps. [Look at what I did in `resources.html`](https://github.com/privacytoolsIO/privacytools.io/blob/i18n/_includes/sections/resources.html#L5-L26) for a more complete example. ## `en.yml` You can see how I've formatted this file already, but basically it should be like: ``` PAGE: KEY: "String" ``` Where "Page" is the section being translated, Key is a brief description, and "String" is the English text. At the top there is also a "Global" section, for strings that are reused a bunch on different pages: ``` global: further_reading: "Further Reading" ``` Pretty much everything needs to go into this file, and then this file will automatically be used as the base in Weblate upon which all translations will be based on (which will be far easier).

abbluiz commented

2019-09-28 00:37:19 +00:00

(Migrated from github.com)

How is this going so far? I'm the main Portuguese maintainer at https://www.privacidade.digital/ (https://github.com/PrivacidadeDigital/privacidade.digital)

I confess I was a little concerned with this idea because if you separate the strings in some ways, it would be difficult or impossible to translate to certain languages (if you break sentences). Also, the privacytools domain and basically all of its services (including forum posts that are referenced on the site) are not translated to other languages. There is also a lot of links to external sites that are only available in English. Making all of the strings available as yaml files and on one domain would not allow other language maintainers to change these links to more appropriate ones, or add sections related to their countries.

However, there might be some way to work around this with jekyll-multiple-language-plugins using translated pages and permalinks.

How is this going so far? I'm the main Portuguese maintainer at https://www.privacidade.digital/ (https://github.com/PrivacidadeDigital/privacidade.digital) I confess I was a little concerned with this idea because if you separate the strings in some ways, it would be difficult or impossible to translate to certain languages (if you break sentences). Also, the privacytools domain and basically all of its services (including forum posts that are referenced on the site) are not translated to other languages. There is also a lot of links to external sites that are only available in English. Making all of the strings available as yaml files and on one domain would not allow other language maintainers to change these links to more appropriate ones, or add sections related to their countries. However, there might be some way to work around this with jekyll-multiple-language-plugins using translated pages and permalinks.

dawidpotocki commented

2019-09-28 00:49:49 +00:00

(Migrated from github.com)

How is this going so far? I'm the main Portuguese maintainer at https://www.privacidade.digital/

It's meh.

I confess I was a little concerned with this idea because if you separate the strings in some ways, it would be difficult or impossible to translate to certain languages (if you break sentences).

Yeah, that's an issue.

There is also a lot of links to external sites that are only available in English.

We can add <a href=""> links to yaml file.

> How is this going so far? I'm the main Portuguese maintainer at https://www.privacidade.digital/ It's meh. > I confess I was a little concerned with this idea because if you separate the strings in some ways, it would be difficult or impossible to translate to certain languages (if you break sentences). Yeah, that's an issue. > There is also a lot of links to external sites that are only available in English. We can add `<a href="">` links to yaml file.

jonah commented

2019-09-30 22:08:26 +00:00

I confess I was a little concerned with this idea because if you separate the strings in some ways, it would be difficult or impossible to translate to certain languages (if you break sentences).

This is probably the main issue to figure out. Jekyll is not super fantastic as an easily translatable platform.

> I confess I was a little concerned with this idea because if you separate the strings in some ways, it would be difficult or impossible to translate to certain languages (if you break sentences). This is probably the main issue to figure out. Jekyll is not super fantastic as an easily translatable platform.

abbluiz commented

2019-10-10 17:24:16 +00:00

(Migrated from github.com)

I confess I was a little concerned with this idea because if you separate the strings in some ways, it would be difficult or impossible to translate to certain languages (if you break sentences).

This is probably the main issue to figure out. Jekyll is not super fantastic as an easily translatable platform.

Yeah, I have used jekyll-multiple-languages-plugin before and I had a hard time doing the SEO as well. I used jekyll-seo plugin but it does not work together with this translation plugin, so I had to stop using it and implementing the SEO myself with Liquid template language and the translation plugin.

> > I confess I was a little concerned with this idea because if you separate the strings in some ways, it would be difficult or impossible to translate to certain languages (if you break sentences). > > This is probably the main issue to figure out. Jekyll is not super fantastic as an easily translatable platform. Yeah, I have used jekyll-multiple-languages-plugin before and I had a hard time doing the SEO as well. I used jekyll-seo plugin but it does not work together with this translation plugin, so I had to stop using it and implementing the SEO myself with Liquid template language and the translation plugin.

djoate commented

2019-10-29 02:16:09 +00:00

(Migrated from github.com)

There have been a lot of updates in general over the past few months to the strings and etc., so master may need to be merged into i18n again if possible.

It seems that my general fixes to typos in the strings from PR https://github.com/privacytoolsIO/privacytools.io/pull/1418 will have to reapplied to this branch, but I suppose that will happen after we've moved all the existing strings over first.

Should we be bolding the service/software/addon name when it appears in the first sentence of a description paragraph? (Related issue: https://github.com/privacytoolsIO/privacytools.io/issues/1420) This seems to only hold currently for the browser addons; as a result, this bold formatting looks inconsistent across the site.

For example, these are the strings for Decentraleyes:

decentraleyes: "Decentraleyes"
  decentraleyes_title: "Decentraleyes: Block Content Delivery Networks"
  decentraleyes_description: "emulates Content Delivery Networks locally by intercepting requests, finding the required resource and injecting it into the environment. This all happens instantaneously, automatically, and no prior configuration is required."

The corresponding lines of .html:

{%- capture title5 -%}{% t browser_addons.decentraleyes_title %}{%- endcapture -%}
{%- capture descr5 -%}<strong>{% t browser_addons.decentraleyes %}</strong> {% t browser_addons.decentraleyes_description %}{%- endcapture -%}

{% include cardv2.html
title=title5
image="/assets/img/addons/decentraleyes.png"
description=descr5
website="https://decentraleyes.org/"
forum="https://forum.privacytools.io/t/discussion-decentraleyes/269"
gitlab="https://git.synz.io/Synzvato/decentraleyes"
firefox=""
chrome=""
opera=""
%}

Notice how there are <strong> </strong> tags around the title in the description.

But this is the string for LineageOS:

  lineageos_descr: "LineageOS is a free and open-source operating system for smartphones and tablets, based on the official releases of the Android Open Source Project. It is the continuation of the CyanogenMod project."

and the corresponding lines of .html at mobile-operating-systems.html:

{%- capture mobile_os_lineageos_labels -%}warning:contrib:{% t global.contrib %}{%- endcapture -%}
{%- capture mobile_os_lineageos_descr -%}{% t mobile_os.lineageos_descr %}{%- endcapture -%}

{% include cardv2.html
title="LineageOS"
image="/assets/img/tools/LineageOS.png"
description=mobile_os_lineageos_descr
badges="info:AOSP"
labels=mobile_os_lineageos_labels
website="https://www.lineageos.org/"
github="https://github.com/LineageOS"
%}

There have been a lot of updates in general over the past few months to the strings and etc., so master may need to be merged into i18n again if possible. It seems that my general fixes to typos in the strings from PR https://github.com/privacytoolsIO/privacytools.io/pull/1418 will have to reapplied to this branch, but I suppose that will happen after we've moved all the existing strings over first. --- Should we be bolding the service/software/addon name when it appears in the first sentence of a description paragraph? (Related issue: https://github.com/privacytoolsIO/privacytools.io/issues/1420) This seems to only hold currently for the browser addons; as a result, this bold formatting looks inconsistent across the site. For example, these are the strings for Decentraleyes: ```yml decentraleyes: "Decentraleyes" decentraleyes_title: "Decentraleyes: Block Content Delivery Networks" decentraleyes_description: "emulates Content Delivery Networks locally by intercepting requests, finding the required resource and injecting it into the environment. This all happens instantaneously, automatically, and no prior configuration is required." ``` The corresponding lines of .html: ```html {%- capture title5 -%}{% t browser_addons.decentraleyes_title %}{%- endcapture -%} {%- capture descr5 -%}<strong>{% t browser_addons.decentraleyes %}</strong> {% t browser_addons.decentraleyes_description %}{%- endcapture -%} {% include cardv2.html title=title5 image="/assets/img/addons/decentraleyes.png" description=descr5 website="https://decentraleyes.org/" forum="https://forum.privacytools.io/t/discussion-decentraleyes/269" gitlab="https://git.synz.io/Synzvato/decentraleyes" firefox="" chrome="" opera="" %} ``` Notice how there are `<strong> </strong>` tags around the title in the description. --- But this is the string for LineageOS: ```yml lineageos_descr: "LineageOS is a free and open-source operating system for smartphones and tablets, based on the official releases of the Android Open Source Project. It is the continuation of the CyanogenMod project." ``` and the corresponding lines of .html at `mobile-operating-systems.html`: ```html {%- capture mobile_os_lineageos_labels -%}warning:contrib:{% t global.contrib %}{%- endcapture -%} {%- capture mobile_os_lineageos_descr -%}{% t mobile_os.lineageos_descr %}{%- endcapture -%} {% include cardv2.html title="LineageOS" image="/assets/img/tools/LineageOS.png" description=mobile_os_lineageos_descr badges="info:AOSP" labels=mobile_os_lineageos_labels website="https://www.lineageos.org/" github="https://github.com/LineageOS" %} ```

djoate commented

2019-11-10 04:01:55 +00:00

(Migrated from github.com)

With 218a610c3f (diff-510dea53868741105f8d9db818243f0f) comes the use of {{ site.name }} and similar. These variables don't work when you put them into en.yml and it seems the only solution so far is to break sentences up which isn't optimal since sentence structures vary between languages.

With https://github.com/privacytoolsIO/privacytools.io/commit/218a610c3f1b63ddcb9fa355c84bbf39f6650a15#diff-510dea53868741105f8d9db818243f0f comes the use of `{{ site.name }}` and similar. These variables don't work when you put them into `en.yml` and it seems the only solution so far is to break sentences up which isn't optimal since sentence structures vary between languages.

jonah commented

2019-11-10 05:57:04 +00:00

👍 I guess I'm most likely going to revert most of those changes.

djoate commented

2019-11-10 19:23:34 +00:00

(Migrated from github.com)

@JonahAragon Here is a crude solution that I have found.

Have the string in en.yml some sort of format specifier for the site name:

  sponsors_of: "Sponsors of %SITE_NAME"

In the corresponding .html file (in this case, sponsors.html), capture it and use the replace filter:

.
.
.
{% capture Sponsors_of_Privacytools %}{% t sponsors.sponsors_of %}{% endcapture %}

<div class="col-12">
  <div class="row">
    <div class="mx-auto text-center">
      <div class="mt-4 mb-4">
        <h1>{{ Sponsors_of_Privacytools | replace: "%SITE_NAME", site.name }}</h1>
      </div>
.
.
.

Such a solution will have to be done for every string that has to use site.name. Does this sound acceptable?

@JonahAragon Here is a crude solution that I have found. Have the string in `en.yml` some sort of format specifier for the site name: ``` sponsors_of: "Sponsors of %SITE_NAME" ``` In the corresponding .html file (in this case, sponsors.html), capture it and use the replace filter: ```html . . . {% capture Sponsors_of_Privacytools %}{% t sponsors.sponsors_of %}{% endcapture %} <div class="col-12"> <div class="row"> <div class="mx-auto text-center"> <div class="mt-4 mb-4"> <h1>{{ Sponsors_of_Privacytools | replace: "%SITE_NAME", site.name }}</h1> </div> . . . ``` Such a solution will have to be done for every string that has to use ``site.name``. Does this sound acceptable?

djoate commented

2019-11-11 03:44:21 +00:00

(Migrated from github.com)

I know we might be in a bit too deep into jekyll-multiple-languages, but I was wondering why we chose to use jekyll-multiple-languages plugin.

If we're open to changes, there is also this plugin that Signal uses: https://github.com/signalapp/jekyll-simple-i18n

From what I saw, their way of doing it makes the source more readable. Here is what a part of index.html of their demo site looks like:

  <body>
    <h1>{% translate Hello world! %}</h1>
    <p>{% translate This is an example. %}</p>

    <p>{% translate This string will appear in English on generated pages until a translation is added to the YAML file for that language. %}</p>
  </body>
</html>

The raw strings come out automatically into a YAML after building (although the IDs are a bit verbose):

---
our_website: |
  Our website  

hello_world: |
  Hello world!  

this_is_an_example: |
  This is an example.  

this_string_will_appear_in_english_on_generated_pages_until_a_translation_is_added_to_the_yaml_file_for_that_language: |
  This string will appear in English on generated pages until a translation is added to the YAML file for that language.  

more_strings_to_look_at: |
  More strings to look at.

It's initially aimed towards Transifex but it's possible to use it for other translation systems too such as our Weblate install. I don't work with Ruby though, so not sure how to implement it.

I know we might be in a bit too deep into jekyll-multiple-languages, but I was wondering why we chose to use jekyll-multiple-languages plugin. If we're open to changes, there is also this plugin that Signal uses: https://github.com/signalapp/jekyll-simple-i18n From what I saw, their way of doing it makes the source more readable. Here is what a part of index.html of their demo site looks like: ```html <body> <h1>{% translate Hello world! %}</h1> <p>{% translate This is an example. %}</p> <p>{% translate This string will appear in English on generated pages until a translation is added to the YAML file for that language. %}</p> </body> </html> ``` The raw strings come out automatically into a YAML after building (although the IDs are a bit verbose): ```yml --- our_website: | Our website hello_world: | Hello world! this_is_an_example: | This is an example. this_string_will_appear_in_english_on_generated_pages_until_a_translation_is_added_to_the_yaml_file_for_that_language: | This string will appear in English on generated pages until a translation is added to the YAML file for that language. more_strings_to_look_at: | More strings to look at. ``` It's initially aimed towards Transifex but it's possible to use it for other translation systems too such as our Weblate install. I don't work with Ruby though, so not sure how to implement it.

djoate commented

2019-11-24 01:15:18 +00:00

(Migrated from github.com)

With 218a610#diff-510dea53868741105f8d9db818243f0f comes the use of {{ site.name }} and similar. These variables don't work when you put them into en.yml and it seems the only solution so far is to break sentences up which isn't optimal since sentence structures vary between languages.

This has now been solved in 9d2f363e31

> With [218a610#diff-510dea53868741105f8d9db818243f0f](https://github.com/privacytoolsIO/privacytools.io/commit/218a610c3f1b63ddcb9fa355c84bbf39f6650a15#diff-510dea53868741105f8d9db818243f0f) comes the use of `{{ site.name }}` and similar. These variables don't work when you put them into `en.yml` and it seems the only solution so far is to break sentences up which isn't optimal since sentence structures vary between languages. This has now been solved in https://github.com/privacytoolsIO/privacytools.io/pull/1510/commits/9d2f363e317d7a89cbde4883a0ccc5c34fa13721

jonah commented

2019-11-24 05:22:55 +00:00

@djoate I'm removing most of the {{ site.name }} variables in #1508 (pending review) because they didn't make sense anyways.

djoate commented

2019-11-25 01:03:37 +00:00

(Migrated from github.com)

Almost all of the site has been keyed into separate PRs. See https://github.com/privacytoolsIO/privacytools.io/pull/1509#issuecomment-557949464 for more details.

LostCrew commented

2020-06-05 12:32:59 +00:00

(Migrated from github.com)

Just chiming in to say I'm happy to help providing new Italian translations or contribute to the technology-related discussion 👍

🎉 1

abbluiz commented

2020-08-24 17:43:56 +00:00

(Migrated from github.com)

How can I help you guys with this?

I can see there are many things left to do according to OP, but also @djoate mentioning separate PRs that solves most things?

How can I help you guys with this? I can see there are many things left to do according to OP, but also @djoate mentioning separate PRs that solves most things?

blacklight447 commented

2020-10-08 08:36:03 +00:00

(Migrated from github.com)

@jonaharagon Should probably be able to help you out

djoate commented

2020-12-12 08:47:11 +00:00

(Migrated from github.com)

@abbluiz Our work wasn't done in time, so we would likely need to rekey large portions of the site to start up work again.

Most of the existing work is in the i18n-simple branch (https://github.com/privacytools/privacytools.io/pull/1509/commits) which is where I pretty much single handedly keyed almost the entire site at that time. My comment on the draft pull request https://github.com/privacytools/privacytools.io/pull/1509#issuecomment-578556388 gives some things left to do, but might be changed since more things have been changed on the site:

For things to do before this can be considered ready,

Localize breadcrumbs

There's still pull request https://github.com/privacytoolsIO/privacytools.io/pull/1535 open that needs to be merged

I think a policy for pull requests adding content should be made (for example, are contributors are expected to tag the new strings they make in pull requests?)

Maybe look into getting the self-hosted Weblate as a subdomain of privacytools.io

A simple merging of master into this i18n-simple branch to update the contents won't work cleanly due to the fundamental changes in how the strings are used between master and i18n-simple

This has been a massive timesink for me in the past, and it's also time-sensitive work (if we wait too long, things get out of date quickly). I think we should be hesitant about progressing with this until we get some commitment to review and merge from a member of the @privacytools team. Would also need someone from the team to setup Weblate support again

@abbluiz Our work wasn't done in time, so we would likely need to rekey large portions of the site to start up work again. Most of the existing work is in the `i18n-simple` branch (https://github.com/privacytools/privacytools.io/pull/1509/commits) which is where I pretty much single handedly keyed almost the entire site at that time. My comment on the draft pull request https://github.com/privacytools/privacytools.io/pull/1509#issuecomment-578556388 gives some things left to do, but might be changed since more things have been changed on the site: > For things to do before this can be considered ready, > - Localize breadcrumbs > - There's still pull request https://github.com/privacytoolsIO/privacytools.io/pull/1535 open that needs to be merged > - I think a policy for pull requests adding content should be made (for example, are contributors are expected to tag the new strings they make in pull requests?) > - Maybe look into getting the self-hosted Weblate as a subdomain of privacytools.io A simple merging of `master` into this `i18n-simple` branch to update the contents won't work cleanly due to the fundamental changes in how the strings are used between `master` and `i18n-simple` This has been a massive timesink for me in the past, and it's also time-sensitive work (if we wait too long, things get out of date quickly). I think we should be hesitant about progressing with this until we get some commitment to review and merge from a member of the @privacytools team. Would also need someone from the team to setup Weblate support again

👍 1

Oymate commented

2021-01-10 06:20:16 +00:00

(Migrated from github.com)

Is the link down? https://weblate.nablahost.com/projects/privacytoolsio/

👍 2 😕 2

This repo is archived. You cannot comment on issues.