Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: International Language Support #779

Open
abraunegg opened this issue Jan 19, 2020 · 8 comments · May be fixed by #1494
Open

Feature Request: International Language Support #779

abraunegg opened this issue Jan 19, 2020 · 8 comments · May be fixed by #1494
Assignees
Labels
Feature Request Feature Request | Enhancement Request Future Work - Planning Required
Milestone

Comments

@abraunegg
Copy link
Owner

One of the major gaps that this client has is support for languages other than English - so that the client output is more understandable and meaningful to non-native English speakers.

I would like to gauge interest in whether it is worth pursuing an "internationalisation" patch to the client, most likely configured as a parameter detected / passed in at compile time + a value switch in the configuration file.

Obviously, to support languages would require a consistent approach to logging messages, have these stored in a specific file, where, depending on the language selected, the right message used.

The only way though to support languages other than English (US, UK, AU etc) would be from the wider folk using the client to contribute a translation and submit a PR, then have this PR reviewed by at least one or two other folk who are that language native speakers.

Initial support that I can think of which might be required:

  • English (EN-US)
  • English (EN-GB, EN-AU, EN-NZ etc)
  • French
  • German
  • Spanish
  • Japanese
  • Chinese (Simplified)
  • Russian

Thoughts?

@abraunegg abraunegg self-assigned this Jan 19, 2020
@Rondom
Copy link

Rondom commented Jan 19, 2020

A PR is quite a bit of overhead for "just changing one translation-string". There are quite nice UIs such as
https://weblate.org/ which make the process easier.

@abraunegg
Copy link
Owner Author

@Rondom
Thanks for the suggestion - will have to look into this further as an option

@tyger
Copy link

tyger commented Feb 2, 2020

The installation process for Raspbian (on Raspberry Pi) is quite evolved on it's own and it might be to complicated to comprehend for person that is not well familiar with English already.

@abraunegg
Copy link
Owner Author

@tyger

The installation process for Raspbian (on Raspberry Pi) is quite evolved on it's own and it might be to complicated to comprehend for person that is not well familiar with English already.

Can you help expand on this?

The installation instructions for Raspbian is really straight forward - and really no differnt to any other Linux OS's as documented - https://github.com/abraunegg/onedrive/blob/master/docs/INSTALL.md#dependencies-raspbian-armhf

Curious as to why you think it is more complex on Raspbian ?

@tyger
Copy link

tyger commented Feb 4, 2020

@abraunegg Sorry if I confused you. Well, probably I chose too strong words, what I meant is that even though it doesn't seem too complicated, but being able to walk all the way from installing Raspbian, then build the dependencies, the onedrive client and install it you need at least basic level of English and that is the reality. Hence I'm assuming that it might not be very beneficial.
Don't get me wrong, I don't think that installation is more complex on Raspbian, but it's not just sudo apt install onedrive either.

@asdf8dfafjk
Copy link
Contributor

Not a direct answer but some (somewhat incohreent) questions/thoughts...

  1. I know no telemetry but do you know if you have mainland chinese users? https://blog.yoocare.com/how-to-access-onedrive-in-china/ says OneDrive is blocked in China but accessible using VPN .

  2. Chinese simplified is only used by mainland china so you might want to add two other locales: zh_TW and zh_HK. I know you won't convert yourself but I still figure the following piece of information might come handy if/when you do decide to do i18n.

2a) zh_TW, used in Taiwan, uses traditional chars. ROC and PRC use almost the same language, and in most cases one can convert just traditional characters to simplified characters for non-technical terms to get the PRC version from ROC. Here's a list (just for G, click other chars)- http://www.iicm.org.tw/term/termb_G.htm where the first column is Taiwan Mandarin and second is Chinese Mandarin. (Nothing for "cloud storage" though :)). This list itself is crazy because they use traditional characters even for PRC version .

2b) zh_HK (HKG uses traditional but their language is different).

Also might I suggest using https://github.com/projectfluent/fluent if you decide to go down this path? Made by mozilla, and I've heard good things about it. No D API right now but you could call rust code using FFI (If I'm free I might be able to help you ...)

Adding to weblate suggestion, there is also crowdin (never used either ... )

@abraunegg abraunegg added the Feature Request Feature Request | Enhancement Request label Nov 6, 2020
@asdf8dfafjk
Copy link
Contributor

@abraunegg I might be able to provide (really terrible) chinese (simplified) translations if you want. The first step to plan would be extracting out the word list in english

@abraunegg
Copy link
Owner Author

In the next few weeks I will be submitting a PR to provide international language support as this is long overdue.

Initially, support will be for the following languages:

  • EN-AU (default)
  • EN-US

I am looking for folk to do the following:

  • Perform some performance regression testing to see if the logfile lookup / response has any negative performance over the existing client - I can do my testing, but this is nothing as compared to some real-world usage
  • Check that nothing 'major' has been missed with application output

Once done, adding a new language will require:

  1. Updating the application code to reference the new translation
  2. Translating each of the application responses (100+) into the new language for correct application output

I will be looking to the community to assist here with creating new language translations.

@deskpronto
This might be a better approach to ensure your language updates for Portuguese are included by default, and you do not have to maintain a separate fork & constantly make changes when a new application version is released.

@abraunegg abraunegg added In Progress Currently being worked on and removed Future Work - Planning Required labels Apr 13, 2021
@abraunegg abraunegg changed the title Feedback Request: International Language Support Feature Request: International Language Support Apr 29, 2021
@abraunegg abraunegg added this to the v2.4.13 milestone May 27, 2021
@abraunegg abraunegg linked a pull request May 28, 2021 that will close this issue
@abraunegg abraunegg modified the milestones: v2.4.13, v2.4.14 Jul 1, 2021
@abraunegg abraunegg modified the milestones: v2.4.14, v2.4.15, v2.4.16 Nov 22, 2021
@abraunegg abraunegg modified the milestones: v2.4.16, v2.5.x Mar 9, 2022
@abraunegg abraunegg added Future Work - Planning Required and removed In Progress Currently being worked on labels Apr 20, 2022
Repository owner locked and limited conversation to collaborators Apr 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Feature Request Feature Request | Enhancement Request Future Work - Planning Required
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants