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

Very translates updated, some keys for some strings fixed and linked with crowdim. https://crowdin.com/project/1655556 #1916

Closed
wants to merge 0 commits into from

Conversation

unnamed-orbert
Copy link
Contributor

No description provided.

@ImprovedTube
Copy link
Member

ImprovedTube commented Jan 5, 2024

hi! @unnamed-orbert wow, thank you so much for caring!
Can you (/we) set up sync between crowdin and github?

not sure i can merge/publish with incomplete or empty translation files.
As long as message exists in no locale file, we can use any character like spaces and emojis and have an international version already. (When missing in locale files, we fall back to the message's names). - So this is what i added sometimes for quick development. (#1490). Yet to allow any translation, we had to stick to the naming (abcABC_) that chrome required in these json files. So we to add the messages to every language file at once only with https://github.com/code-charity/youtube/blob/master/py/locale.py, not to fall back to the strangely formatted name in any language anymore. and prepare each a translator's work. So we should keep to always do that. And locale.py can could upgraded to be a Github Action or fully automated bot, "https://github.com/code-charity/Bulk-Contributor" : " - the following (almost rare) task alone might still has been done a million times in history (by 1000s of people):
Browser-Extension translations: Syncing lines from their English language file (en/messages.json) to all their other existing languages files......"

- Additionally / Alternatively, we can make the UI attempt to unCamelize or un_snakealize any name (in case it is not part of the user's locale)

more interestingly, we could stop using the standard /_locales/... to allow a smart, efficient tree of translations, where the - international name equals the message's name in the code). And where users could prioritize multiple languages/locales:
#1543

@unnamed-orbert
Copy link
Contributor Author

OK, but it is not necessary to fill in all the locale files because there are many cases where phrases are translated into other languages that are not available in (/en/messages.json)!

You used the phrases as keys and they can be easily modified to be invoked by the main translation file (/locales/en/messages.json) thus making it easier to be mass translated by crowdim or another mass translation tool

But it is not possible to translate sentences with special characters outside the "abcABC_" scheme

@ImprovedTube
Copy link
Member

hi! :) @unnamed-orbert

it is not necessary to fill in all the locale files...

what do you mean? i tried to say: Once we create a language file, then we have to start with a copy of english and add every every message there immediately, or use our locale.py, because we cant tell the browser to default to english at incomplete language files but the keys (abcABC_) are shown. (Besides if we or manage to change the rule in the Chromimum repo, or write our own logic beyond the standard.)

@unnamed-orbert
Copy link
Contributor Author

unnamed-orbert commented Jan 7, 2024

hi! -_- @ImprovedTube

Sorry, but at the time I read it I didn't understand that you linked each of the translation files independently.

If we know that non-English users won't have the extension translated completely, why not translate it directly into the global language?

So I think it wouldn't be a problem if you added all the Keys to /en/messagens.json for your extension!

Crowdim fills in strings that have not been translated from English with original phrases!
You would just need to add a giant warning so users know the reason for the partial translation

Below are some errors that can be found in my Brazilian Portuguese language with what I mentioned above!

"it is not necessary to fill in all the locale files..."

v12163v512135v11623v5
v123116v25311251v3dqwd
v125613v521361v

1c234152c31125631c12

@ImprovedTube
Copy link
Member

ImprovedTube commented Jan 8, 2024

hi @unnamed-orbert thank you! :)
yes, in fewer words: This repo is what users get. So before merging, we need every new key to appear in all locales at once (55 languages files or more) (which can be synced with the help of locale.py or crowdin? or anyway)
(with the only exception was while appearing in 0 language files)


Crowdim fills in strings

Can you set up sync between crowdin and github?

So we need some github action to always get the latest files from there.

whats 'de-GU'?

'es-ES', 'ar-SA', 'ko-KR'
=synonyms?

@unnamed-orbert
Copy link
Contributor Author

Hey, I realized here that the problem we're trying to solve is a very old problem.
I propose the following solutions:

  • Use Crowdin for mass duplication and translation into the most popular languages (Would solve 30% of the problem)
    Unfortunately Crowdin has a duent restriction of 60000 words!

  • Use manual translation by requesting a notice on the website, on the project page and in the extension for languages that are not on Crowdin
    (Manual checking will be complicated)

  • Update localy.py file list manually

I'm sure we don't have the time or patience to be able to replicate text for more than 100 files, I don't have the knowledge at the moment to make a bot.

If possible, I would be happy if you could merge the changes I made and correct the keys by adding them to the _locales/en/messagens.json file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants