Help translate the web interface via weblate #3183
Comments
|
I did a registration with github and proposed a change on a translation. |
|
I played a bit with the tool and it works surprisingly good! From what I understand it is possible to manually trigger a commit (like #3190) or set it to create a PR every x hours based on the recent changes. Instead of PRs we could also allow it to directly commit those changes, however I'd leave this off for now. Cool thing is we can also host it on our own if weblate changes their policies, which I don't see coming anytime soon but still a requirement I'd say. |
|
Thanks for clarification. I have done some translation in luci-app-statistics and saved this. |
|
Currently there are the two options to auto commit every 24h or perform it manually - as I just did. This however ended up in a somewhat messy PR as people started to translate also Portuguese and Russian files. I set it up that from now on PRs are squashed by author, meaning whatever you do in 24h will become a single commit. |
|
It is possible to add the weblate git repository via |
|
Seems to work well. Please continue with this in case further changes are needed. |
|
What is the mechanism here? Each new translation via weblate gets spammed to all LuCI committers? (I guess we can unsubscribe this PR to get rid of the spam, but sounds strange if all future translations are still tied to that one PR. ) |
|
@hnyman sorry for that! I will see how to disable these notifications! The weblate service updates daily a PR with a single commit per author. This way we don't end up with x unmerged PRs for translations. @feckert wrote
The weblate team initially setup the service but made a small mistake, I fixed that and the missing components should now be available. |
|
Another 300 mails, but the storm is over and whoever survives the 200k new lines of PO files in the next git pull should look into a nicely translated future. I'll leave this open for further requests. |
aparcar
changed the title
|
I see that when translating an App (e.g. DDNS), a string that I modify is "Enabled" and is also modified in all apps with that word to translate. I mean, in one App it means one thing and in another it means something else even if it is the same word in English. I don't know if it can be deactivated or dodged. |
|
Hi @castillofrancodamian please don't crosspost issues, I responded to your forum.openwrt.org message. |
|
How is translation supposed to work for release branches? I see that there were some updates to openwrt-19.07 after it was branched off (e.g. dd0c932 and 83a7292), but not all translation updates seem to end up in the 19.07 branch. I fixed several translation mistakes in 19.07.0-rc1 and it would be nice to have the fixes in the final 19.07 release. |
|
I think this depends on @jow- , I'd be okay with moving all translations over to 19.07 just before release freeze or set a public date for a 19.07 translations freeze. |
|
I planned to do some scripting to sync 19.07 translations with master ones by using the master po files as translation catalogs for the branch ones. That should ensure consistency |
|
Hmm. These weblate PRs have no clear author to be contacted, so I will likely fix those conflicts myself. But I am not sure what would be the correct workflow in future. Probably merging the current weblate PRs before syncing translations files? There has also not been much discussion how these should be handled daily. So far @aparcar or @jow- have mainly applied PRs, partially manually, I think. Thus I wonder what is the actually the correct workflow with these weblate PRs:
|
|
I don't know what's the best approach but would be happy not being in charge of it 🙄 Maybe things are simplified by using the weblate github integration. Most issues (seem) to appear by weblate being out of sync, while the app (hopefully) triggers a rebase on every commit to luci.git. |
Well, you introduced it... Can you at least answer my previous questions:
Apparently the conflicting commits from yesterday have been removed automatically. (Spanish, if I remember right). Probably they have been somehow pushed back for translation/checking. Is that supposed to happen? |
Fair enough. I think I wanted to say to distribute the merge capabilities.
I wonder if the SoB line is important for translation updates. If not, the GitHub PR merge should be fine. The problem seem to be syncing.
I think so, however it bloats the git log. Maybe we should only do so once a week? Maybe I got your questions wrong. From what I understand using the Weblate-GitHub-App allows to set a push rate to daily or weekly, so the entire merging could be done automatically. I guess part of the issue is that when using PRs they stay open for multiple days and are out of sync at some point. |
|
Is weblate borderline unusable for anyone else here? |
|
@MartB I think it depends where you are, I tried it before in Honolulu and it barely worked, using it now in Leipzig works fairly well. Maybe we as a bigger project should consider to donate some money for faster servers. I'm against self hosting as it'd be yet another service to maintain... But this is just my personal though. |
|
@aparcar Self hosting would be a possibility but also requires money, time and an active maintainer/sysadmin. |
|
It seems, that Weblate has conflict and it could not merge the new translations. Can someone check it and try to solve the conflict? |
|
Well, the conflicts seem to be mainly due to the recent "typo corrections", either spelling or case changes... Looks like the typo corrections have caused some 50 conflicts there, as they have been made in another repo at the same time as there has been translation going on in weblate. Example of conflicts: |
|
And some of those conflicts seem to be just header meta data conflicts. Too bad. |
|
@aparcar @jow- As a vanilla weblate user, I have not yet figured out how often/why/when weblate actually tries to pull new sources from us. I fixed a dozen conflicts yesterday and merged that, and weblate took maybe 20 hours to notice that we have new upstream LuCI sources. Now I have fixed the next conflicts from the translations done meanwhile. I currently wonder if it will take again almost a full day for the changes to get noticed at weblate, so that new conflicts will get generated in the meanwhile... Likely the "free plan" (or whatever we currently have) has a pretty slow update polling frequency, but still sometimes weblate seems to try updating several times per hour, so the updating frequency varies. So, can those who have some admin rights to weblate, please check if there is something to be configured to enable a somewhat more regular update trials. Ps. |
Don't exactly know the process, but a linking command if nothing has been edited in the config file, checks if „SHA-256“ is the same as example, if so replaces the English text to desired under # (so that no unwanted configurations are added). |
|
Question: |
|
Well, I got an answer on the forums, anyways, seems like major translation progress has once again locked up the entire „Weblate“ translation. (And here I was about to declare victory with 100% translation on „LuCI-base“ and „Firewall4“; I will still make a victory speech on that, though.) |
|
Welp, the main (and most important translations, such as firewall4) have been done, and as such (on the next general „opkg“ translation update) Lithuanian will be a fully supported language on „LuCI“. |
|
After updating to the latest „opkg“ packages, I noticed, that in „luci-statistics“ did not have translated text. I was able to confirm that this text did not appear in „Weblate“ *Could be considered as a bug report. |
|
I’m not sure what to make this one because all of these strings come from
the actual configuration file
config statistics 'collectd_rrdtool' option enable '1' option DataDir
'/tmp/rrd' option RRARows '288' option RRASingle '1' option RRATimespans
'2hour 1day 1week 1month 1year' option backup '0'
After updating to the latest „opkg“ packages, I noticed, that in
… „luci-statistics“ did not have translated text.
paveikslas.png (view on web)
<https://github.com/openwrt/luci/assets/53124670/b527aff0-0254-43dd-999f-d6ae40657c61>
I was able to confirm that this text did not appear in „Weblate“
paveikslas.png (view on web)
<https://github.com/openwrt/luci/assets/53124670/18e0a16f-0e62-45c5-8892-ef34e514a5b0>
*Could be considered as a bug report.
|
|
Those are actual config values in the config file, and values can differ from the default ones. Not practically translatable |
|
I can imagine that it’s possible if we do a replace when scanning for the
units in a displayed string.
|
|
I also wonder about suggesting a language, that has an active translation prompt, since the explained phenomenon called – „the power of defaults“ is very real. One of two ways I could see this happening, if |
|
The same could be said about: |
It will become very complicated very fast given a number of multi-lingual countries -- would you suggest we give the options of English, German, French, Italian and Romansh for users in Switzerland? In the US, the most spoken language after English is Spanish, however it's not an official language, if something like what you're suggesting is implemented, should we adhere to official languages only or go for the Usability/QoL improvement and also suggest Spanish? If someone would want to take a shot at it, I'd suggest to query the browser language(s) and see if there are any matches for that. But implementing even this simplified approach and integrating the suggestion into the current UI is also a time-consuming and challenging task, I'm not sure if any core/luci devs would want to take it. |
|
Don't reduce the translatable material. The Weblate people are very nice about overshooting the boundaries a bit. |
Well, the U.S.A. doesn't have an official language, though English is de facto. The main point is that, most of these languages are pretty easy to apply to, maybe Russian and French would be somewhat hard, since Africa, Canada, Belgium would be applied and Russian with former USSR (if native language is not available), so Lithuania would not get that suggestion, but Latvia would due to demographics and communication bias of English speakers. |
|
Ok, why is this the single lone string „read-only“? |
|
Well I do hope that my consideration on a dialog box asking the user if they want to switch the language of „LuCI“ was taken on the to-do list someday, I will post easy to add translation strings, which are not in „Weblate“ (for some reason). *„Powered by“, quite ironic, since the latter text „„Lua“ suderinamumo režimas aktyvus“ is translated on the same line. And some of the more difficult ones are already in translated status for example: To be honest, this is much better than I remember, pretty minor mistakes, which we all do. I do hope that a developer who maintains this will see this comment, if not (Let's say 24h.) I will most likely add a bug report, since in all fairness these are bugs by definition and if you want to have a polished product/software, then these should be a piece of cake to fix. |
|
Many of these untranslated texts are literal values that must be passed as such to the underlying configuration, they cannot be fixed easily, or the effort to do so would be unreasonable. For example Same as Others such as the time interval entries are required syntax too, the underlying software simply will not understand You could write a complicated widget that takes the number value and the unit in different inputs, but that would massively complicate the code and would have to be re-done for each micro format. |
|
The main problem is that most of these are already translated in other packages or in the exact same „LuCI-base“ just either unassigned or made to be displayed as literal values and not string. I noticed that a lot of the other apps available on „opkg“ which I did translate do not have these problems, even on the near exact same places of issue. They seem to just simply append <a or %s or <code of the syntax to a string, while keeping the underlining code as it was. This is most likely because the developers of these apps are multilingual (I noticed a lot of Chinese devs). „LuCI“ is not the command line, it's a UI, same as „Windows“ is to the NT kernel. When you go to update, you don't see the syntax of the underlying code, even if what you click is the exact same thing. The text you see in a selection is appended, unless it's hardware specific or external, which is why I never mentioned this: I don't expect this to be translatable text, since it would be very hard or impossible to translate due to the variable of uniqueness that it has, since it access the hardware. But a dialog box to enter with „www.example.com“ as hollow text being „cannot be fixed easily, or the effort to do so would be unreasonable“, like cmon... „Dockerman, Acme, Adblock-Fast“ also don't seem to suffer from these problems at least from what I was able to see from the translation material. Seeing three pages of „LuCI“ displaying the same string of time, but some in English and others in another language is simply stupid, makes the software look cheap. Being able to address these issues, which most of the time is a simple – append code characters from displayed to translatable string, keep everything under the hood the same. |
|
Sorry, I don't follow. The "12hour" string is a configuration value. You can't enter |
We don't need to edit the user editable choice, but whatever, that is a very minor thing, one out of the many given examples can be ignored, the impact of something that you see on a dashboard and a small configuration change being consistent is more important. Now I don't know who exactly is in charge of „LuCI-app-openvpn and example“, so this might not be of your concern, but a lot of strings are also not translated? For some reason, only the first and third tab is translated? Very weird, since all the other tabs are not... |
|
My concern is that we're accidentally directing users to malware domains with that. E.g. The domains Also not all translators might understand the domain name rule constraints when translating a string / syntax element containing "example.org" into their native language. |
|
The english list items in the OpenVPN dropdown field do not stem from code but from description labels in a configuration file: https://github.com/openwrt/luci/blob/master/applications/luci-app-openvpn/root/etc/config/openvpn_recipes To make those translatable, we'd not to convert the uci recipe into JSON or something, extend As for the second screenshot, this refers to The |
Ok, I did not think that „OpenWrt“ would actually use example.com in running code? I always thought that it was a suggestion on how a real input should look like, to give an idea to more or less tech-savyy individuals. Wouldn't that cause errors if „IANA“ changed the website? They themselves say to not use it under operational usage – „While incidental traffic for incorrectly configured applications is expected, please do not design applications that require the example domains to have operating HTTP service.“ |
|
No, it is not actually "used" but users might generate configurations and attempt to try (accidentially apply) them before all values are properly changed. This might cause services to hit such a configured domain. Configuration might also be copy-pasted and put into e.g. a forum post, where google would see the embedded links or domains and make them available in searches etc. Other users looking at a given config might immediately recognize "example.org" as a not properly filled out option while they might overlook "pavyzdys.org" etc. |
|
I wonder if we should add a label like "translation" and have sub issues. If not this thread will grow forever. |
Are there any specific problems having it go to like 1000+? |
Interesting, though I personally think that people knowing of simple „LuCI“ usage, would not make such a mistake. On another note, nearly all of technology/coding textbooks and material use the URL of lrs.lt, I wonder if something like pavyzdys.lrs.lt would work, since it's a government website which should not have any problems regarding malware or takeovers (Domain). In „Weblate“ you can add comments as a maintainer to add context, screenshot or comments. If I am right, you can most likely set that specific string as „needs to be approved“. I think that would address your concerns. |
|
There seems to be a glitch/bug with „Weblate“, where some components are not given sources on a translation, for example: |
|
@dziugas1959 World is full of (small) languages. |
There seems to be a very big Irish patriot, who has way more translations than you could imagine, I was perplexed when I saw that Irish was 100% translated, so I just added the rest for him to finish. Also, it is very disrespectful to most of the world. While 57 sovereign states being Anglo states is quite a lot, it is not the majority. May it be Ireland, Latvia, Finland, Lithuania, they all have populations of millions with even larger blocks of integration (in this case EU) who set a precedent that they are official languages. (A.k.a. Don't have a complex about language dominance in IT) |
|
Issues with the „Openwrt“ domain, errors in „Weblate“: |
Hi, for testing I created an OpenSource account on weblate which gives a nice interface to translate the PO files. To improve the process I'd install the weblate service integration (also available for GitLab an other services) which automatically a) add newly added strings to their translation web interface and b) creates pull request once every now and then when updates via weblate happend.
If anyone is against this approach please let me know. Right now it looks like only 52% percent is translated.
The text was updated successfully, but these errors were encountered: