Jamulus: Allow internationalization

Created on 16 Apr 2020  ·  115Comments  ·  Source: corrados/jamulus

I'd be really happy to provides the project with a French translation for the GUI if a translation mechanism was made available.

feature request

Most helpful comment

@Snayler, @trebmuh Here is a first proposal for the new About dialog:
grafik
In this tab I will list the supported languages and the peoples names who contributed to the translations. How do you like it?

All 115 comments

Same applies to the Wiki/docs ideally. I don't think it's really feasible with Github's wiki though. Perhaps if we moved to Github Pages, but that might cause other issues.

If the docs should be moved elsewhere for being translatable, then I'd encourage to make use of https://hosted.weblate.org/ (it's free software and free to use for free software). Note that, you can use the hosted.weblate to make the GUI component translation too.

Interesting. How would this work in Jamulus's case? For example I notice from Weblate's own docs that they appear to be hosted on Github (there's an "edit" button in the top right which takes you to what I assume is a docs repo with .rst files in it). What I don't understand is how to switch to another language (or is that being auto-detected?), or where the web app is being hosted (Is it Github pages, or perhaps some 3rd party that you can deploy to via Github? - looks rather similar to this site which I see has a language switch as well) Is this the default if you opt for weblate hosting?

I don't understand very well what you wrote @gilgongo . Not a native English speaker here.

Not being a coding person neither, I can tell you how I understand it since I'm using it as a translator for several projects.

  • the jamulus dev(s) set up a translation mechanism (let's say the Qt translation system here)
  • the jamulus dev(s) does ask to hosted.weblate if they're ok to host the project's translation for free (being a free software)
  • weblate says OK (most likely and hopefully :crossed_fingers: )
  • then the dev or/and weblate people (I don't know) make a kind of a "hook" thing which allow to copy the translation file from github to weblate, and back
  • the translators translate online (on hosted.weblate) and the hook take care of integrating things back into the github repo

I hope this helps.

If you need more information, I can maybe ask someone from a project I'm translating on weblate to talk with you on what are the details of the installation of that.

@trebmuh My apologies - I was referring to how weblate might work with the localisation of our documentation, not the application itself. Does weblate help with localising a collaboratively-edited website?

@gilgongo as far as I know, you just feed Weblate with files (.pot/.po or .ts type file, maybe there are other translations mechanism accepted) and translators can start working. I'm not sure with what you call a _collaboratively-edited website_. As an example, zrythm GUI interface and website is translated using hosted.weblate .

By "collaboratively-edited" I mean content created and maintained by more than one person, so that implies things like user permissions and things.

I've got very little experience with internationalisation, but for example if you take something like the Github wiki, or Wordpress, or just flat HTML, I assume the .pot/.po or .ts etc. files have to be integrated into that in some way so that weblate can manage the content independently of the presentation? Apologies, but I'm finding it hard to understand how it would work if we were to decide to internationalise the docs as we have them right now (that is, Github wiki), as opposed to the Jamulus app, which seems less of an issue.

I don't really know how it works at such a low level (only a translator here). You might want to chat with weblate people about that, and/or with people using it as project manager (ie: zrythm as a close example to what you're talking about here - its main dev "alextee" is usually on the #lad IRC channel on freenode). I'm sorry that I can't help you further than that. I still hope this talk was helping in some ways !

OK thanks - that's very helpful. I'll see if I can contact the zrythm project about it!

I have already prepared Jamulus for internationalization from the beginning. In the code you will find a lot of tr() calls, e.g.: https://github.com/corrados/jamulus/blob/master/src/clientdlg.cpp#L51

Using the Qt lupdate tool, you can extract the english text. I did this as an example for the following file:
jamulus_en.zip
You can load this file in the Qt Linguist GUI and do the translations:
grafik
Before you spend too much time on it, we should try it out with some example texts, e.g. the ones on the main windows and see how it works. The modifications inside the Jamulus software should hopefully be small.

I have already prepared Jamulus for internationalization from the beginning. In the code you will find a lot of tr() calls, e.g.: https://github.com/corrados/jamulus/blob/master/src/clientdlg.cpp#L51

Yes, I saw that in the code. Good thinking :wink:

Let me know if/when a .ts file is ready for translation and I'll start providing a French version of it.

Finally I have done a very first implementation of the translations. For a test I added some German texts:
grafik
The translation files are here: https://github.com/corrados/jamulus/tree/master/src/res/translation

If you want to start the French translations, then you should clone the Git repo, open the file https://github.com/corrados/jamulus/blob/master/src/res/translation/translation_fr_FR.ts in QLinguist and do the translations. When you are done then create a pull request.

Maybe it is a good idea that you start with just a few translated texts, make a pull request and I can then generate you a Jamulus versino with which you can do a test that everything works for you.

Nice, I'll start the Portuguese translations.

EDIT:
Question: There's some dialogs I'm not sure I should be translating. For example, on CAboutDlgBase, there a TextLabelVersion which seems like a placeholder for the text defined on CAboutDlg. What should be done in these cases?

Also, can we add translator next to the author in the about dialog? Like so:
Autor: Volker Fischer; Tradução: Snayler

In the About dialog white text box we have this: "We would like to acknowledge the contributors listed in the Github Contributors list". Additionally I could add a text for listing the translators.

Well, it would not make sense to have the direct mention of the translators on the About Window without directly mentioning all other contributors who, IMHO, have made more significant contributions. So I'm happy with the "Github Contributors List" link.

@corrados : nice.

I've done a few strings translation as requested. See #176 .

In the About dialog white text box we have this: "We would like to acknowledge the contributors listed in the Github Contributors list". Additionally I could add a text for listing the translators.

It'd be great.

...her contributors who, IMHO, have made more significant contributions.

Well, that's only a PoV. For someone not able to read/understand English, having a good translation in his/her mother tongue is much more important than pretty much any other feature.

Well, that's only a PoV. For someone not able to read/understand English, having a good translation in his/her mother tongue is much more important than pretty much any other other feature.

Yes, it's only my opinion, hence the "IMHO" acronym. I do understand your PoV, it's just that I'm fluent in English and I actually prefer to have all my systems and programs in English than in my mother tongue, as I can better understand technical texts and instructions that way. That's why I value more contributors who actually program features into the software than translators.

On the other hand, I did spend most of today translating, checking and re-checking all the strings on the translation files, I can say it's no easy task. Also, what's not needed for me might be needed for someone who doesn't fully grasp the English language and wants to learn how the software works and what each setting does, so I see your point.

Maybe just have one field for the translator and each language would have it's translator(s) named.

On another note, I found that no strings for most of the dropdown menus were included in the translation files, and I would like to be able to translate some options as it would match the translated explanations better.

My plan is to re-design the About dialog. My plan is to list all the contributors (code development, documentation, translation).

I could do the Spanish translation. Does the 'translation_es_ES.ts' file need to be created or could I just work with the 'translation_de_DE.ts' file (later changing the extension) seeing as it's still empty?

Great, I will prepare a file for your spanish translation.

I could do the Spanish translation.

Please wait for some days before you start. I want to change something in the texts soon.

Ok!

Ok, I think I am done now with the modifications. If you like you can start now your translations using the latest Git master commit.

@Snayler, @trebmuh Here is a first proposal for the new About dialog:
grafik
In this tab I will list the supported languages and the peoples names who contributed to the translations. How do you like it?

:+1:

I'm having trouble selecting the language on 3.5.3git. I'm using --translation, but I'm not sure what to input next to select the Portuguese language.

I just changed it in the latest version so that translation is enabled by default. So you do not need to add any command line argument to enable translation anymore.

I should automatically select the language based on your operating system language selection. I guess your OS is setup to be in english language?

Just installed it in a Spanish OS in virtualbox and the UI is correctly displayed in Spanish. I'll have to make a few small changes now that I can see it in the flesh.

@corrados, yes, my OS is in English. Could you include a drop down in the Settings for language selection? Would it be hard to do?

The translation files are included in the binary so that we do not have separate files. I do this by using the .qrc resource management. In that file I specify the language by <qresource prefix="/translations" lang="pt">. Then I use the QTranslator load() function to load the translation. But I cannot specify a language to be loaded with the load() function. This is done inside the QTranslator class.
Of course this is doable but the way the translations are stored and loaded would have to be changed. And also we would need the GUI controls and setting storage implemented. So it is not so easy to do it unfortunately.

@corrados : here are some strings which aren't translated and doesn't seem to be translatable (ie: not in the .ts file):


While right-clicking on the field where it's written "trebmuh" on this picture:

jamulus-paste

_(works with a bunch of other fields like this one)_


While right-clicking on the horizontal scroll bar on the bottom:

jamulus-scrollhere


Any "What's this?" to get info displayed:

jamulus-whatsthis


From the French .ts file:

  • see lines 1694/1695 & 1699/1700. I'm guessing that this one should be displayed in the "Musician profile" windows, probably with a "What's this?" on the alias/name field
  • lines 741/742 looks to be missing from being displayed too
  • lines 1393/1394, it seems that this is also a "What's this?" pop up which should be displayed while right-clicking in the "Connection Setup" window. But I can't access such a pop up info in the "Connection Setup" windows

These texts in your screen shots are Qt internal. I have no idea how we could translate them actually.

see lines 1694/1695 & 1699/1700. I'm guessing that this one should be displayed in the "Musician profile" windows, probably with a "What's this?" on the alias/name field

Yes, as you can see here:
grafik

lines 741/742 looks to be missing from being displayed too

This is a tool tip, just move the mouse of ther GUI control:
grafik

But I can't access such a pop up info in the "Connection Setup" windows

When I use the What's this? function, I get:
grafik

@corrados : I've asked @jpcima to have a look about the Qt internals texts translation since he have done that several times already and he already went in with the #221 PR. @jpcima : merci !

I'll have a look at the other things.

OK, I found those texts @corrados . I was confused since most of the "what's this?" popup texts can be accessed with a right-click, but not those 2 ones and another one I discovered here:

jamulus

And I was surprised to see the mouse-overing one (the 2nd picture in your previous message) since I wasn't aware of "mouse-overing info" on Jamulus GUI and I found another one here:

jamulus-2

Note that it seems to me that this part is marked as translatable, but isn't in the .ts translation files. Can you please have a look to why?

Can you please have a look to why?

That was a bug in the code. I just fixed that. Now it should work for you.

@corrados nice! Thank you.
I've found a typo in the source, please find the #227 PR.

This Issue is to support internationalization in Jamulus in general. Recently there was a new Issue about a specific new language, e.g.: https://github.com/corrados/jamulus/issues/249
I think since the general internationalization support is done in Jamulus, I should close this issue and if new languages should be added, a new Issue for that specific language should be created. So I close this one now.

I plan to make a new Jamulus release on this Sunday to fix, e.g., the Dutch translation issue we recently observed. I have changed some things in the GUI which had effects on the translation.

@corrados : I've push the French translation to 100% with #263 . Hope it can make it into 3.5.4 .

Yes, sure. It will go into the 3.5.4. Thank you for the update.

Oh, I just saw that you have based your translation on an older version of the translation file. I updated the files now with the latest code and now I can see that there are some texts vanished and there are some new ones. Its not much. Can you please take a look again at your translations on the latest Git code?

Should be done with #265 .

BTW, do you now if we (the translators) are supposed to do something with the "vanished" strings?

Actually not. I guess they are as a reference if the text has just changed a little bit so you can re-use it. I have not found out how to delete these in the Qt Linguist GUI but after a while at least they could be removed manually from the .ts file.

Have you tried with lupdate -no-obsolete ?

Thank you for the info. This seems to be useful to clean up the .ts files after all translation is ready and released.

I reopened this Issue because I want to use it to announce future Jamulus releases so that you can get the translations in shape for that release (this was requested in https://github.com/corrados/jamulus/pull/349#issue-432650522).

There are already a lot new features implemented in Git. Therefore I plan to make the next release 3.5.7 on Sunday, 28th of June (i.e. in one week). It would be good to have updated translations the day before (Saturday) if possible.

@genesisproject2020, @melcon, @dzpex, @jerogee I saw that you have not posted in this Issue. Please subscribe to this Issue to get the latest informations on scheduled Jamulus releases.

Ok i Will update soon the new features

In data 21 giugno 2020 10:07:06 Volker Fischer notifications@github.com
ha scritto:
>

There are already a lot new features implemented in Git. Therefore I plan
to make the next release 3.5.7 on Sunday, 28th of June (i.e. in one week).
I would be good to have updated translations on Saturday if possible.

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Inviato con AquaMail per Android
https://www.mobisystems.com/aqua-mail

I’ve created a first translation to Swedish yesterday. How can I test the translation in the gui to tweak it?

If you like you can make a merge request with your .ts file and I update it with the latest changes and create the .qm file. If you want to do it yourself, you must use the lupdate and lrelease tools from Qt.

@corrados thanks for pinging us beforeward. French translation done in #385

The .desktop file, which has the description of Jamulus used by application launchers, would also benefit from a check by translators - currently it only has English and French.

I will check the desktop file.

FYI: I plan to make the next release 3.5.9 on Sunday morning, 18th of July (i.e. in one week). It would be good to have updated translations the day before (Saturday) if possible.

Done for the French one on #449

Swedish translation updated #378

Running 3.5.9 I see the combo box for the language selection, however where the names there are coming from? Some doesn't start with capital letter. Also I don't see a (pt_BR) - it looks like the (pt) is the for pt_BR

image

however where the names there are coming from?

Its the output of the https://doc.qt.io/qt-5/qlocale.html#nativeLanguageName Qt function.

t looks like the (pt) is the for pt_BR

Yes, that's correct.

I forgot to mention that the previous image was on a Win10. On OS X El Capitan(10.11.6) I see this:

Screen Shot 2020-07-20 at 10 53 49 AM

FYI: I plan to make the next release 3.5.10 on Sunday morning, 16th of August (i.e. in one week). It would be good to have updated translations the day before (Saturday) if possible.

@corrados done for the French translation. See #502 .
It'd be great if there wouldn't be strings changes until release, then the French translation will be 100% translated.

Thank you for your updates.

It'd be great if there wouldn't be strings changes until release, then the French translation will be 100% translated.

Just today, Hk1020 had a good point regarding one of the new texts: https://github.com/corrados/jamulus/issues/476#issuecomment-671228931
I think it is worth to change the text since it really makes the functionality clearer. I hope you agree with me. Unfortunately, as a result, you should then update your translations again.

@corrados see #519

It'd be really good to have a "strings freeze period" policy one week before a release, then it'll save translators' time.

Perhaps nitpicking, but for the sake of consistency: for next release, s/people/musicians/g.

Same applies to the Wiki/docs ideally. I don't think it's really feasible with Github's wiki though. Perhaps if we moved to Github Pages, but that might cause other issues.

@gilgongo @corrados @ignotus666, We are trying to help spread the word from Buenos Aires, Argentina, and we are starting a Facebook group to help circulate knowledge and experiences within the Spanish-speaking Jamulus communities.

It would be amazing if we could start translating some of the wiki pages to Spanish. Would you agree that we just create translations by appending "-es" at the end of the urls? For example, the Spanish version of wiki/Getting-Started would be wiki/Getting-Started-es. This is what they do here, and it seems easily transferable to other languages as well.

We could also add a (es | de | it | ... ) snippet at the top of the translated pages, linking to the other language versions.

What do you think?

@diegodlh Interesting approach!

Your wiki seems to have about the same number of base pages (25 perhaps?) as ours. The pages on ours change perhaps on average once a month in some way, with some more frequently than others. These changes are usually related to new features, or suggestions that people make which either I or others add. BTW there is also the user manual which is in Git so translators would need to know how to use that (BTW @corrados can you remind me why the manual is in Git? I seem to recall a good reason for it...)

How do you manage notifying translators of changes? It's quite common that a change is made, then updated/reformatted or reverted over a day or so before settling on the final version. So it would need some kind of "approval" to avoid wasting people's time I think. Perhaps Github tickets? This also implies perhaps restricting who can edit wiki pages or changes might be made to any page in any language without anyone knowing. And some way of notifying wiki changes.

I think we all submit translations via git pull requests so using Git shouldn't be a problem. I suppose we could just let changes to the wiki "settle in" for a few days before notifying translators, which could be done as it is now - by writing on this thread (or another one created specifically for this purpose), which all translators should be subscribed to.

I'm not sure I understand the process of creating the translated wiki pages but that's because I'm clueless about this kind of stuff. I do recall starting to translate some of the wiki but didn't go very far because there was nowhere to put the translations.

BTW, @othertranslators: what do you use to translate .md files? I use OmegaT with the Okapi filters plugin and it works very nicely, but I'm curious about what other people use.

Pd: In fact I strongly recommend the use of OmegaT or a similar tool that uses translation memories as it helps enormously to maintain consistency, quickly identify changes and share translations of multiple files among translators with a single .tmx file.
It can also handle .ts files but QtLinguist is better for that as OmegaT doesn't change the status of translated segments and they still show up with a '?' in QtLinguist.
But again, I'm open to hearing about alternatives.

It would be amazing if we could start translating some of the wiki pages to Spanish

Would the Google Translator be an option? Is it possible to integrate this translater in a Github Wiki?

Would the Google Translator be an option? Is it possible to integrate this translater in a Github Wiki?

They can be a useful tool for translators to work with, but automatic translations are to be avoided.
By the way, deepl is working much better for me than Google Translator.

So it would need some kind of "approval" to avoid wasting people's time I think. Perhaps Github tickets? This also implies perhaps restricting who can edit wiki pages or changes might be made to any page in any language without anyone knowing.

@gilgongo, I think the spirit of a _wiki_ is precisely that anyone can edit. That's what makes it so rich. I understand that's the point of having the "Restrict editing to collaborators only" option unset in the Github repo settings.
I guess that if the project needs better controlled documentation, it can have some markdown files in the git repo, like the manual you mentioned.

I understand and agree that control and structure are needed to translate the software. But here, for the collaboratively-edited wiki, I think that a Wikipedia-like approach might be better, where different language versions are somehow based one on another, but with relative independence as well. As quoted from the project I cited before (which I'm not related to, btw): "Wiki is a bit special in this regard, since it's online help where you don't need to stick with original sentence too much."
We are not a big community, and I think that too much restrictions and bureaucracy may discourage rather than encourage collaboration from non-technical users.

How do you manage notifying translators of changes?

The wiki seems to be a separate git repo (https://github.com/corrados/jamulus.wiki.git). Here there are some ideas to keep track of changes. For example, one could follow the Atom feed.

BTW, @othertranslators: what do you use to translate .md files? I use OmegaT with the Okapi filters plugin and it works very nicely, but I'm curious about what other people use.

@ignotus666, I understand this would apply for more tightly controlled documentation inside the main repo (like the software manual), as mentioned above
The online Crowdin service provides markdown support and GitHub integration, but it doesn't seem to provide integration with custom gits such as corrados/jamulus.wiki.git. Alternatively, one could use their integration tool, but that would require having a service running separately somewhere.
Weblate does seem to support pulling and pushing to corrados/jamulus.wiki.git, but apparently it doesn't support markdown files.

tl;dr
So, if you agree, I can just go ahead and create empty placeholder pages for a Spanish wiki (one per English wiki page) following the directory structure used by the ArchiSteamFarm's project wiki (you can clone it from here). And then we can invite people from the Spanishs-speaking community to start translating into those placeholders. What do you think? I can actually do it and show you how it'd look like; I think it would be easier.

I have a few files already translated if you want to do a test with them.

OmegaT isn't just handy for keeping translations consistent, but also for the task of translating itself as it extracts the text into easily-translatable segments instead of free-handing it on plain docs and having to glance continually from one open file to another, navigating tags, etc. But I also understand it has a learning curve that not everyone may be willing to climb. I like the idea of each language community expanding the wiki as they see fit but I think the starting point should be just a straight translation of the English version. Then let it branch off from there. As a translator used to working with CAT tools I'm more comfortable with just sticking to a reference and translating from there as it makes life easier, but I see how this can also become a constraint.

Yeah, Deepl is pretty impressive (Google translate is sh*te) but I agree that while it does a fairly good job, it's still some way from being able to replace a proper human translation. And long may it stay that way...

@diegodlh

I think the spirit of a wiki is precisely that anyone can edit. That's what makes it so rich.

Indeed. But without putting too fine a point on it, what you see on the wiki is not the result of a Wikipedia-style collaboration :-)

Just to be clear, I'm not worried about vandalism or how we might coordinate change notifications (your link shows that the latter is probably OK). My primary concern is bugs getting into the documentation. Repetition of information in multiple places that then needs updating in multiple places. There is also the problem of accumulation of information without structure.

Be that as it may...

I can actually do it and show you how it'd look like; I think it would be easier.

That would be good - mainly as I'm slightly confused as to what we're talking about here. Are you proposing to maintain the wiki via git and not via the web UI as currently? Or do you mean you're just going to create a bunch of placeholder *-ES.md files and push them to the wiki to be edited by the web UI from there?

EDIT: Am I right in thinking the wiki at https://github.com/JustArchiNET/ArchiSteamFarm/wiki does not have public editing via the web UI turned on?

what you see on the wiki is not the result of a Wikipedia-style collaboration :-)

I've seen you've put a lot of effort on it @gilgongo, thanks! Most Wikipedia articles seem to be created by single authors as well, after all :)

My primary concern is bugs getting into the documentation. Repetition of information in multiple places that then needs updating in multiple places. There is also the problem of accumulation of information without structure.

I'm concerned about information repetition as well. Regarding bugs and unstructured accumulation, I guess the English wiki is at the same risk right now, open as it is. Maybe we can find someone in the Spanish-speaking community willing to maintain the Spanish wiki as enthusiastically as you are maintaining the English one, and help keep both in sync!

All in all, I think I'd rather have an imperfect Spanish wiki, than no Spanish wiki at all.

As mentioned above, an alternative would be to have the English wiki as the base version, and have controlled translations. To have it open to non-technical collaborators, I think the ideal would be to use platforms such as Weblate or Crowdin. However, as mentioned earlier, Weblate doesn't support md files, and Crowdin does but interaction with the wiki git repo would require additional configuration.

Are you proposing to maintain the wiki via git and not via the web UI as currently? Or do you mean you're just going to create a bunch of placeholder *-ES.md files and push them to the wiki to be edited by the web UI from there?

I was proposing the second: creating a bunch of placeholder *-ES.md files (with the appropriate folder structure to allow translated sidebar and footer as well) and push them to the wiki to be edited by the web UI. However, I did some tests (which I had to interrupt because of life, you know) and there are some things which I don't like:

  • The Spanish sidebar and footer can only be edited via git (not via the web UI)
  • If someone changes the title of an article via the web UI, it is moved out from the Spanish folder and the English sidebar and footer are shown instead.
  • Same thing happens with new articles: if created via the web UI, they are saved outside the Spanish folder and the English sidebar and footer are shown.

Then, I think a better solution may be to have a separate repo (e.g., jamulus-wiki-es) which only holds the Spanish wiki. I'm gonna do it as soon as I find some free time again, and I'll post it here so you can tell me what you think :)

Am I right in thinking the wiki at https://github.com/JustArchiNET/ArchiSteamFarm/wiki does not have public editing via the web UI turned on?

I guess they must have the "Restrict editing to collaborators only" option enabled.

I can volunteer to keep the Spanish version updated. If I can get a shout-out whenever the English version gets edited I'll update the Spanish one.

I've been slowly ploughing my way through the translation of the wiki in my spare time and have about 50% of it done. I reckon I should have it completed by the end of next week/beginning of the next.
As long as I can just upload or copy/paste the content of the translated .md files into the placeholders that would be fine by me. I'm comfortable with my translation workflow and would rather not use web-based translation tools (when I asked I was thinking more about local tools) for several reasons that are neither here nor there.

I can volunteer to keep the Spanish version updated.

Amazing, @ignotus666!!

If I can get a shout-out whenever the English version gets edited I'll update the Spanish one.

I understand you can just subscribe to the atom feed (https://github.com/corrados/jamulus/wiki.atom) using any rss/atom feed reader (e.g., Feedly).

and have about 50% of it done

Cool! We translated the figure in "Getting started" for the introductory talk we gave last weekend. We also translated Volker's paper figure, but I think it's nowhere in the wiki. I'm attaching both in case you need them (couldn't prevent them from embedding, sorry).
ecosistema_jamulus
cliente_servidor_es

As long as I can just upload or copy/paste the content of the translated .md files into the placeholders that would be fine by me.

Great! @corrados, I can create diegodlh/jamulus-wiki-es, or even better I can create a "jamulus" organization and create jamulus/jamulus-wiki-es instead. What do you think? Or would you rather create corrados/jamulus-wiki-es instead and have me upload the placeholders to the wiki there?

I have translated sidebar and footer already for my tests. I'll try and have the placeholders ready (with links to the English versions, and breadcrumbs at the top) in these days.

I can create diegodlh/jamulus-wiki-es [...] would you rather create corrados/jamulus-wiki-es instead

There is no jamulus organization so I would either put it in your Git account or mine. I think it would be better to put it in your account since you will maintain it and not me (I cannot speak spanish).

@diegodlh

I guess they must have the "Restrict editing to collaborators only" option enabled.

I must say I think that is the better method if we are going down the route of multiple languages (and a separate repo for Spanish).

I respect your view on Wikipedia-style openness (I myself have been reasonably active on Wikipedia), but I am nervous about the effect of anyone being able to edit the English version and therefore affecting what might be hundreds of pages and unknown man hours.

We translated the figure in "Getting started"

BTW if you want you can try using the "source" of the diagram I used for Jamulus here https://github.com/corrados/jamulus/issues/64#issuecomment-613875648

FYI: I plan to make the next release 3.5.11 on Sunday morning, 20th of September (i.e. in about one week). It would be good to have updated translations the day before (Saturday) if possible.

Swedish translation updated.

@ignotus666, I uploaded the Spanish wiki placeholders as promised here. For consistency, I left the filenames the same as in English, and I think it would be better if we leave them like that. Given that the Github wiki makes the title from the file name, I added a header line at the top of all files: let's write the translated titles there. I didn't translate these titles, the sidebar or the breadcrumbs because I thought you may have some titles already, and I didn't want to overwrite what you'd done already. I did translate the footer though.

@corrados, @gilgongo, @ignotus666, regarding the manual, considering it is the only piece of documentation inside the git repo, do you think it would make sense to have a manual-es.md file in the official repo, next to manual.md? I think that would be neater.

I added a language selector at the top of the English and Spanish wiki sidebars. I wanted to add a language selector at the top of each article, but they are quite a few. I tried to do it automatically, but it wouldn't let me push to the wiki repo. @corrados, do you think you could do it? Otherwise, maybe me and @ignotus666 could do it manually (I already did for Home and Getting Started). The commands in bash would be:

git clone https://github.com/corrados/jamulus.wiki.git
cd jamulus.wiki
for file in `ls -I "_*"`
do
    filename=${file%.md}
    echo -e "( en | [es](https://github.com/diegodlh/jamulus-es/wiki/$filename) )\n" | cat - $file > temp && mv temp $file
done
git commit -m 'Add language selector'
git push

Thank you all! I think this step will be very important for the Spanish-speaking Jamulus community! :)

Oh, and just one more thing: I read elsewhere that it is not obvious that the wiki shares the same license as the code, because they live in separate repositories. Many suggest to state a separate license notice in the wiki. Do you think we could add this note to the wiki footer? Shall we use GPL 2.0? Or would you rather use CC BY SA 4.0 instead?

@diegodlh Sure - we can put that in the footer. CC BY is better for docs I think, as the GPL is really all about executable code.

do you think it would make sense to have a manual-es.md file in the official repo

Seems to make sense to me.

I added a language selector at the top of the English and Spanish wiki sidebars.

Nice! 👍

@diegodlh Great stuff! Ok, I'll start populating the placeholders with what I've got. I think I might have all the translations done by tomorrow or the day after.

@diegodlh, what would be the best way to push my translations to the wiki? I forked your jamulus-es repo but realised that the wiki doesn't get carried over. Then I tried pushing a commit to yours but this obviously fails because I can't authenticate with my username and password. Should I just copy + paste directly into the repo in edit mode? That's fine by me but e.g. the sidebar and footer aren't visible for editing.

Never mind, sorry - I didn't see the edit icon for the sidebar and footer... When the translations are done I'll get round to editing the links in the texts so they lead to the right place.

have a manual-es.md file in the official repo

Jonathan agreed. @ignotus666, are you working on the manual as well? If Volker also agreen, then you may submit a pull request when you have it ready.

When the translations are done I'll get round to editing the links in the texts so they lead to the right place.

@ignotus666, just to make sure, I think I'd keep the wiki file names like the English version, to aid maintenance. So, editing links should mean changing them from, say, https://github.com/corrados/jamulus/wiki/Command-Line-Options to https://github.com/diegodlh/jamulus-es/wiki/Command-Line-Options, right? (this has the disadvantage that pages not listed in the sidebar have to be looked for in English :-/ )

BTW, just gave a look to what you have uploaded already: it looks so great! I'm so happy! Let me known when you are done. I'm sure the people from the Spanish-speaking Jamulus community group in FB will be delighted to have this!!

CC BY is better for docs

@gilgongo, I think that too. I had suggested CC BY SA because I thought the share-alike clause made it more similar to the GPL under which the code is licensed. What do you think? Let me know and I'll add this legend to the footer: "This wiki is available under the Creative Commons Attribution[-ShareAlike] License", and similar legend in the Spanish version.

I forked your jamulus-es repo but realised that the wiki doesn't get carried over. Then I tried pushing a commit to yours but this obviously fails because I can't authenticate with my username and password.

@ignotus666, you can clone this repo to get the wiki: https://github.com/diegodlh/jamulus-es.wiki.git. But yes, in order to push I think I have to add you as a collaborator to diegodlh/jamulus-es. I can do that for sure, no problem. If you agree, let's use the web ui and allow editing for everyone like in the English version, and if we see that makes things complicated we can enable editing for collaborators only. We can always follow new edits with the Atom feed: https://github.com/diegodlh/jamulus-es/wiki.atom

@diegodlh I'll start working my way through the manual when I'm done with the wiki. If there's an agreement on hosting the file alongside the English version, I'll make a pull request.

@ignotus666, just to make sure, I think I'd keep the wiki file names like the English version, to aid maintenance. So, editing links should mean changing them from, say, https://github.com/corrados/jamulus/wiki/Command-Line-Options to https://github.com/diegodlh/jamulus-es/wiki/Command-Line-Options, right? (this has the disadvantage that pages not listed in the sidebar have to be looked for in English :-/ )

Most of the links already redirect to the right place within the Spanish wiki, as it's not an absolute path like you wrote above, but what I assume to be a relative path. They need editing where they take you to a specific paragraph within a section - I did a test and it's simple enough.

@ignotus666, you can clone this repo to get the wiki: https://github.com/diegodlh/jamulus-es.wiki.git. But yes, in order to push I think I have to add you as a collaborator to diegodlh/jamulus-es. I can do that for sure, no problem. If you agree, let's use the web ui and allow editing for everyone like in the English version, and if we see that makes things complicated we can enable editing for collaborators only. We can always follow new edits with the Atom feed: https://github.com/diegodlh/jamulus-es/wiki.atom

Yeah I figured out how to clone the wiki but ran into the authentication problem. I agree that from now on editing can be done in the web ui.

So many messages, I lost the context... Do I have to do something now or are you translators happy with what you can do with the wiki web ui?

@corrados I think it's fine as far as the wiki goes. Just one thing we'd like to know your opinion about: if we translate the manual.md file, can it live alongside the English version or should it go in the Spanish wiki or elsewhere? @diegodlh I'm thinking that if we were to do it properly, it should have screenshots of the application in Spanish (it references a lot of gui items), which would add a significant amount of clutter. Maybe it would be better if it had its own folder in your repo. Ideally the link to the manual in the app's help menu would take you to the Spanish manual if the language chosen is Spanish, but I don't know what that would involve. What do you guys think?

if we were to do it properly, it should have screenshots of the application in Spanish (it references a lot of gui items), which would add a significant amount of clutter. Maybe it would be better if it had its own folder in your repo

@ignotus666, I see your point, and it would be perfectly OK for me to have it in the diegodlh/jamulus-es repo; I would add you as collaborator. But if @corrados agrees, I definitely think it would make more sense to have it in his repo, next to the English manual. We could have an 'es' folder for the screenshots to reduce clutter.

I think it's fine as far as the wiki goes

Only thing I would add is that I'd appreciate it if @corrados could run the commands below to automatically add the ( en | es ) language selector at the top of all English wiki articles. Otherwise, I guess @ignotus666 or I could do it manually one by one.

git clone https://github.com/corrados/jamulus.wiki.git
cd jamulus.wiki
for file in `ls -I "_*"`
do
    filename=${file%.md}
    echo -e "( en | [es](https://github.com/diegodlh/jamulus-es/wiki/$filename) )\n" | cat - $file > temp && mv temp $file
done
git commit -m 'Add language selector'
git push

Otherwise, I guess @ignotus666 or I could do it manually one by one.

I actually do not want to mess with the Wiki sources. I would prefer if you do it manually.

I would prefer if you do it manually.

Done.

@diegodlh CC BY-SA would be fine I think (sorry, only just seen your note on this).

I know some people might not like the idea, but given there is now the additional work of a translated wiki, messy/poorly thought-through additions to the original English version can lead to significant disruption and wasted time with corrections, etc. to both versions (and possible future ones).
I would like to formally request that editing of the wiki be restricted, where submissions take place with pull requests that are reviewed before being added (can that be done for the wiki too?). I propose @gilgongo for that role (if he accepts) in view of the fine work he has done until now. Given the recent announcement by @corrados regarding adding contributors to the project it shouldn't be a problem.
There were quite a few changes made and in order to avoid too big of a backlog of pending updates I recently updated the Spanish wiki - only to find a couple of days later that these changes had been rearranged again. I'm not pointing any fingers; just stating that I think uncontrolled access without a review process is a bad idea. It sounds good at a theoretical level - but in real life it can be a nightmare if we want to keep it organised and coherent.

@ignotus666 That's fine by me. Coincidentally, I commented to @ann0see today about this. I share your worry that an open-access wiki will basically cause the documentation to become unmanageable over time and work against the adoption of Jamulus. Jamulus should (and can be) simple to use without having to read pages and pages of stuff or learning about "interesting" technical concepts which may interest us, but nobody else.

Yup, if new users looking for simple instructions are confronted with a wall of command-line geekery there's a strong chance many will simply turn away or just get more confused. And I think leaving it open to people adding random snippets of information (however good the intentions) will just lead to an incoherent mess. Anyone who thinks they have a contribution to make is still entirely free to do so; it's just about reviewing it by someone who has a strong grasp of the wiki (i.e. @gilgongo ) before it actually gets published.

It'd also make updating translations much less tedious, as all changes could be viewed at a glance. But that would depend on whether it could happen with a pull request process, like with the main code - is that the case?

I agree but I understand that it is not possible to use a pull request process with the wiki. If you close it to collaborators only, collaborators of the corrados/jamulus repository will be able to make changes like everyone can now, and non-collaborators would have to submit an issue. I think that to do what you would like to do, the documentation would have to be part of the repo (or maybe a separate doc repo), like the manual.

I agree but I understand that it is not possible to use a pull request process with the wiki. If you close it to collaborators only, collaborators of the corrados/jamulus repository will be able to make changes like everyone can now, and non-collaborators would have to submit an issue. I think that to do what you would like to do, the documentation would have to be part of the repo (or maybe a separate doc repo), like the manual.

Tasmota uses the a github repository to maintain the documentation at https://github.com/tasmota/docs and then show them at https://tasmota.github.io/docs/
All changes submitted as a PR (and wiki-like easy access to the edit button in each page top right indicated with a pencil symbol, see https://tasmota.github.io/docs/Commands/ as an example)

This looks interesting. I'm going to look into the software they use.

Edit: they use mkdocs which doesn't support translation. Let's wait what @gilgongo thinks.

Relating to the wiki and its internationalisation in the light of the fact that it's also not indexed by Google, I think we should move to Github pages and use a Jeckll i18n plugin https://github.com/corrados/jamulus/issues/615#issuecomment-699595007 (note that I don't _actually_ know what that involves, mind you!)

Not only does this solve the issue of uncontrolled updates, it also means that we would have control over the look and feel of the site overall, opening up the possibility of making Jamulus look friendly to non-technical users.

As an aside, I believe we may be reaching the point of being over-documented. Jamulus should be (and actually is, compared to many software projects) simple to understand. Achieving this requires a degree of control though, as @ignotus666 notes.

We have some nice new features and some important bug fixes already so it makes sense to schedule a new release: I plan to make the next release 3.5.12 on Sunday morning, 4th of October. It would be good to have updated translations the day before (Saturday) if possible.

When launched with a French locale with a wrong JACK rate, it gives me:

jamulus-5 12-oubli-trad-en

After setting up the 48kHz and relaunching jamulus, its GUI is in French as expected.

Strange thing is that it looks to me that it's supposed to be translated already.

PS : @corrados are you a drummer?

The problem is that this error message occurs before CLocale::LoadTranslation is called in main.cpp. It's a hen-egg-problem. The translation needs the settings and the settings need the client to be constructed. While constructing the client object, the error message occurs.
And yes, I am a drummer :-).

The problem is that this error message occurs before CLocale::LoadTranslation is called in main.cpp. It's a hen-egg-problem. The translation needs the settings and the settings need the client to be constructed. While constructing the client object, the error message occurs.

OK, thanks for the explanation. I'm not a coder but can't we make it so is load the locale setting before anything else?

And yes, I am a drummer :-).

So we might have played a bit together yesterday while I was testing a 3.5.12 LibraZiK package.
_(I'm mainly a drummer too, but I was playing a rocky guitar)_

FYI: I plan to make the next release 3.6.0 on Sunday morning, 25th of October. It would be good to have updated translations the day before (Saturday) if possible.

I‘ve added the translators to a group called translators in the new homepage repository. Please accept the invitation.

@ann0see :

I‘ve added the translators to a group called translators in the new homepage repository. Please accept the invitation.

Done.

@corrados : done on #693

FYI: I plan to make the next release 3.6.1 on Sunday morning, 22th of November. It would be good to have updated translations the day before (Saturday) if possible.

@dyeopensource wants to add Hungarian translations, see https://github.com/corrados/jamulus/issues/760.

FYI: I plan to make the next release 3.6.2 on Sunday morning, 13th of December. It would be good to have updated translations the day before (Saturday) if possible.

@corrados : thanks for the "nbsp" changes, forgot to commit these.

Thx for the info. Unfortunately I could not make it by now. I am done only
with about the half of the texts.

Volker Fischer notifications@github.com ezt írta (időpont: 2020. dec. 7.,
H, 17:10):

FYI: I plan to make the next release 3.6.2 on Sunday morning, 13th of
December
. It would be good to have updated translations the day before
(Saturday) if possible.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/corrados/jamulus/issues/77#issuecomment-740015722,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6J6AYHI7EMX3KWKEZE4RDSTT5AVANCNFSM4MJYFW4Q
.

Was this page helpful?
0 / 5 - 0 ratings