Re: [libreoffice-website] Italian translation of LO website - is something stuck?
Hi Christian, Many thanks for your answers; allow me another bunch of (quite stupid, indeed) questions, just to understand the matter. Il 19/05/23 12:13, Christian Lohmaier ha scritto: check out what happens on the download page in italian [1]; the right-sided buttons are not translated and I see their values are in the HTML code not translated. That is expected/by design. Ok, good to know. To have translated sidebar buttons you need to provide translated content in silverstipe backend on the download page. the "Sidebar Button" field labeled "Sidebar buttons, see https://redmine.documentfoundation.org/issues/1023; the ticket shows sample syntax Thanks for the information. I will involve the translation group on this specific snippet and get back to the list/to you in private when ready. Or the donations page [2] [...] Oh, should not have been a problem for years. Maybe a problem years back when the strings were added to the website but were not available on weblate, but that's long fixed since then. I have the impression this has been left as it is now since then. No one to blame, here - possibly missed communication from the translation team. We'll try to get better in communicating from our side (NLP project, I mean). but for some reason the exported files on the website server do not have the string for italian (but for a couple of others) In the meantime Marina did a quick check for other languages and it seems Italian is indeed not the only one (for sure we know of partial translations on Spanish, French and Chinese zh-cn). But I am sure you have a better understanding of its impact as of now. Are you aware of any issues in applying new translation efforts on the website? Not problems like that - the translations aren't synced regularly (then again strings also change very rarely), but I was not aware of incomplete transfer of strings. Yeah, well, it doesn't make sense to check each week for translations, indeed. I hoped there was a simple, less manual way to deal with it, but no need for it if complicates too much and doesn't give much of an advantage. Sparing you from tedious and manual operations was another clear goal, but that depends on the push to have that in place - which seems very low to me, with the current status-quo, and quite risky, while not requiring your efforts for a lot of time. Is Weblate the right tool to source for website translations, then, or this is still Silverstripe? A clear "it depends" (see above) - some parts are translated in weblate (mostly the static downlaod page and donate page strings), but other parts like project-specific stuff like sidebar buttons where each NL project might have different coverage/focus is done in silverstripe. Thanks for clarification. Is there an easy way to recognize which parts are still managed in Silverstripe and the ones that are in Weblate, apart of the obvious "check in Weblate, if the string is not there then it is managed in Silverstripe"? Do you think it is feasible to have some backups for that work and/or a responsible person on each NLP, that are able to verify and in case deploy modifications to the website or it will be mostly useless/painful? I think the Italian NLP project already had someone, but I think he is not so much present anymore. And honestly the migration to new website took/takes longer than expected, it was already decided long ago that the website system will change to the git managed site, so no real work was done on the old site.. Indeed, no need nor point to have the whole website sorted out in haste. With "Git managed site" you meant similar to what happens/have happened with TDF website (so based on Hugo)? Is there any foreseeable time-span in which you think that could land? What's the expected workflow around updating NLP pages? That's still manual, introducing new strings into the system would require manual update of the strings that are available in weblate, and then exporting strings from weblate to silverstripe is also manual since the yaml file needs to meet certain formatting standards/cannot be used directly. Ah, that's quite a bummer - but I guess it is something we can live with for as long as needed to move to a new platform, also given the low frequency of the task. I think it might have been a bug in one of weblate's dependencies that got updated meanwhile, at least when I export the italian website file now I get the DonateTimeHeader string... As said, it is totally possible the results of the bug was there since long, but the bug isn't around anymore. Thank you again so much for the answers and having unblocked the issue, cheers, -- Emiliano Vavassori syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guideline
[libreoffice-website] Italian translation of LO website - is something stuck?
Hi all, It has been brought to my attention by Italian NLP leaders that the LibreOffice website, when viewed in Italian, breaks on translations (for example, check out what happens on the download page in italian [1]; the right-sided buttons are not translated and I see their values are in the HTML code not translated. Or the donations page [2]: the second part of the page is not translated at all). This seems to be a long standing problem (probably years) and we would like to ascertain there is no misunderstanding in the understanding between TDF and the volunteers, here. Translators affirm that the untranslated parts of the website are indeed available and translated inside Weblate. I honestly cannot judge if this is true or not ATM, but it is quite evident there are some not particularly nice partial translations there. Are you aware of any issues in applying new translation efforts on the website? Is Weblate the right tool to source for website translations, then, or this is still Silverstripe? What's the expected workflow around updating NLP pages? Does the same issue occur also on other NLP projects' websites? Is there an automation pipeline to get newer translations applied directly from Weblate to the NLP-specific website or it is still manual work? Would the same process apply for an eventual Hugo-based website? Can someone point out the expected processes/steps, so we can at least evaluate if we can appoint representatives from our NLP community to care for the main website updating (and consequently, other translated web resource)? Many thanks in advance; cheers, [1]: https://it.libreoffice.org/download/download/ [2]: https://it.libreoffice.org/donazioni/ -- Emiliano Vavassori syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/website/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-website] Re: A couple of questions on LO builds
Hi Guilhem, Il 17/03/22 00:24, Guilhem Moulin ha scritto: See https://blog.documentfoundation.org/blog/2019/06/06/libreoffice-6-3-on-linux-a-statement/ (I assume this followed an ESC decision — the dev list probably contains some archives on the discussion and might be a better venue to discuss this :-) Thanks for the pointers. I'm fine with what you provided, no need to further discuss this :) I guess if we desperately need to build for x86 it will be for <6.3 and will be taken from downloadarchive.df.org, at least for the time being. For daily builds we have /current links such as https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@tb87-TDF-dbg/current/ What's the chance that the part before the 'current' changes somehow in the future? That 'tb87' worries me the most :) For stable releases, one can use the trick described at https://listarchives.tdf.io/i/P3QatPuSx3u3UgM3hqC1h46s . $ curl -A 'LibreOffice 0.0 (3215f89-f603614-ab984f2-7348103-1225a5b; Linux; x86_86; BundledLanguages=)' \ https://update.libreoffice.org/check.php | xmlstarlet sel -T -t -v '/inst:description/inst:version' So I'd like to use this one, very handy; but I still remind wget complaining about the delay between release time and that pointer being updated. Reasons behind the delay are *not* being challenged here :) But since the effort of auto-building those AppImages is mostly to have them as soon as a new release is published (as community members ask for the AppImages just hours after release), well, that might fail the goal from the incipit. * As a side note, do you have a tool of choice for triggering such builds? We use Jenkins, like for regular CI. The build environment comes from LODE https://wiki.documentfoundation.org/Development/lode and artifacts are copied to dev-builds.libreoffice.org afterwards. cloph will probably be able to give more details next week after his vacation :-) Thanks for the summary, probably more than sufficient for the moment. I'd return to this when we will replace the binary builds with source ones (if it will ever happen :) ). Cheers, -- Emiliano Vavassori syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/website/ Privacy Policy: https://www.documentfoundation.org/privacy
[libreoffice-website] A couple of questions on LO builds
Hi all, Sorry for the (probably stupid and already addressed several times) questions this mail will surely contain. I'm trying to automate the building of AppImage for LibreOffice, starting from the good work of Antonio Faccioli [1]. For the sake of clarity, those AppImage builds are basically a repackage of the .deb contents from TDF-released packages. I have some questions: * Are x86-based (32bit) builds definitely abandoned? I don't see any x86 builds in the dev-builds.lo.org site nor in download.df.org site; * Is there any other smarter way to know the last available .deb build, both for stable releases and for daily builds, than parsing those pages? * As a side note, do you have a tool of choice for triggering such builds? What is the workflow (in a few words) there? I'm giving Rundeck [2] a spin for this. Cheers, [1]: https://github.com/antoniofaccioli/libreoffice-appimage/blob/master/make_libreoffice_appimage [2]: https://www.rundeck.com/open-source -- Emiliano Vavassori syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/website/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-website] Infra call on Tue, Dec 21 at 17:30 UTC
Hi all,
Il 19/12/21 23:19, Guilhem Moulin ha scritto:
We'll meet at https://jitsi.documentfoundation.org/infra and write the minutes
to https://pad.documentfoundation.org/p/infra . Agenda TBA.
Although most probably I will not be present to the Infra meeting (and I
am sorry, I know this would have been mandatory to discuss proposed
points to the agenda; the discussion can be conducted even here in
written, though), some Directors would like to know Infra's team
understanding around having a PeerTube instance hosted at TDF to serve
the videos that are now served from elsewhere (e.g. the ones from the
Conferences). This would be taken into consideration for the budgeting
round for 2022 at TDF BoD.
To be more specific, we are interested in:
1 - the level of usefulness/likeliness you would see (totally needed,
nice to have, completely useless, dangerous, counterproductive, etc.)
2 - the actual level of knowledge in supporting such instance ("no
knowledge" to "we created the software, so we can do whatever we need to")
3 - willingness to support it (don't want to/prefer not to/more than
happy to do it)
4 - Eventual (estimated) expenses in knowledge building;
5 - Eventual (estimated) expenses for extra virtual
hardware/bandwidth/workforce to implement and support such instance;
6 - Any other consideration you would put on the table for which we
might have not thought about.
If possible, please motivate your answers (more so if on the "negative"
spectrum of possible answers) so I can better proxy that to the Board.
If you will discuss on the Infra meeting and I cannot attend, happy to
read the minutes and then chase here for clarifications, if needed. I'd
strive to participate, though.
Thanks, cheers,
--
Emiliano Vavassori
syntaxerror...@libreoffice.org
--
To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-website] Minutes from the Tue Sep 21 infra call
Il 22/09/21 08:06, Florian Effenberger ha scritto: thanks to all of you for your amazing and precious work for the LibOCon streaming infrastructure - I am really happy to see all this coming to life! Well done! :) Indeed! A big +1 here :) Sorry for not being able to attend to the Infra meeting nor being of any help whatsoever :/ Cheers, and have a good Conference you all :) -- Emiliano Vavassori syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/website/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-website] Infra call on Tue, Apr 20 at 16:30 UTC
Il 19/04/21 02:49, Guilhem Moulin ha scritto: > We'll meet at https://jitsi.documentfoundation.org/infra I heard of some issues today with the TDF Jitsi instance. Is this confirmed or the meeting will be held elsewhere? Cheers, -- Emiliano Vavassori syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/website/ Privacy Policy: https://www.documentfoundation.org/privacy
[libreoffice-website] Today's Infra call
Hi all, Differently from what I planned, I would not be in the condition to attend to the Infra meeting today, I apologize. Please send out the minutes, as always; happy to catch up on them after. If there is anything relevant to be communicated/actioned by BoD by your judgement, please let me know. Regards, -- Emiliano Vavassori, Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/website/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-website] Mysterium jitsissimum tremendum et fascinans
Hi Ilmari, Il 22/04/20 20:18, Ilmari Lauhakangas ha scritto: > What's up with the wild world of conference calls? Let's have a look at > the past, present and future of TDF's Jitsi. Thanks for the recap and the overview for the next future. I still support the idea that Jitsi will help us so much in making public meetings with 20+ people. I'm looking forward for the next iterations, to see if implementations done by Infra team has the expected impact on the user experience. Nonetheless, I see this is too much bound to client settings to be "stable" by itself. Calling Firefox out of the games from the start seems harsh, though. We can state that due to implementation issues with the regards of Firefox, you may use it if in version >77 or with simulcast disabled (we should provide docs to disable it, at least a link). Plus we should briefly clarify that, if indications are not followed, esp. on the FF side, it would thrash others' experience. For sure, we should give much stricter/clearer indications on how to join the meeting for the sake of the quality perceived by all of the participants. Maybe building a wiki page (to be pointed out when calling public meetings) on how to access the Jitsi instance with these caveats (and the other ones pointed out before by Cloph) may quicken and ease it usage, making it also a public point. Ideally, showing it before joining the room would increase also its effectiveness (at least the first time). Cheers, -- Emiliano Vavassori syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/website/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-website] TDF Jitsi instance issues with 20+ people
Hi Florian, hi all, Il 19/03/20 11:11, Florian Effenberger ha scritto: > - it very much looks like the client is the problem That alarms me a lot. My i7 4x CPU was at 8+ load while conferencing with the test. I suspect Chrome is the main culprit there. Will try with Chromium. > - I proposed to verify the results with a test in the official Jitsi > Meet instance, to see if this has the same problems, although I'm not > sure that in the current times that is reliable Good idea. We should try in a non-scholastic time frame (like 17.00 UTC or something like it). > For next Friday's meeting, we have several options: > - As fallback we could use > > - talkyoo, a pure phone-based solution that served us well in the > past. For dial-ins from countries that talkyoo doesn't provide a number > for, there seems a workaround with Google Hangouts. This "bridging" is > not convenient, but does the job. I second this one much. In the end we don't need video streams and maybe a full-fledged audio conferencing system may cope with much more participants and scale better. > - another conferencing system Paolo is using (I don't remember the > name currently) That's BigBlueButton (https://bigbluebutton.org/), which is a more classroom-oriented approach. His instance is hosted on https://bbb.opencloud.lu, if of any interest. Please ask him if you want to try it straight away (paolo.vecchi@tdf). > - Nextcloud Talk, as we do have a Nextcloud instance; but then, we > don't have experience with the videoconferencing module I've just heard more issues than with Jitsi, so... Regards, -- Emiliano Vavassori syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/website/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-website] TDF Jitsi instance issues with 20+ people
Hi all, I'm sorry if I am just replying to Florian's mail, but I will try to take into account all feedback received until now. Il 13/03/20 16:22, Florian Effenberger ha scritto: > Disabling video did not help. I don't know if that can help, but what came to my mind is that the default settings for video in Jitsi is HD. Since there are no specific options for the audio, I would expect that this quality settings could have some impacts on the audio part of the stream as well. Decreasing audio quality a bit shouldn't be an issue. > I looked at the VM during the meeting and the load was at about 8, To me, this is mostly in line with a 8 vCPUs machine at ~100% load. I don't have hw specs of the machine, but I suspect this is really near the actual status of the machine, showing that hw specs can be binding here. Again, only a theory for the moment. > suggesting we can pump up the virtual hardware and see how that goes. > Another option is to host not at our datacenter, but at some cloud > provider with different connectivity. That's another point. More on this below. > The official Jitsi instance seems - given the amount of home office > workers at the moment - rather problematic from what I've heard. Indeed, and the second most recognized one (Framatalk, as pointed out by William) either :-/ > As it's hard to test meetings with 20 people Well, I've seen also testrtc pointed out elsewhere, other than Thorsten (btw, thanks). > I'd propose > - assinging more resources to the VM -> Cloph, can you have a look? > (Guilhem is on vacation right now) > - finding out if there was any major spike in traffic on the VM recently > -> also Cloph, can you have a look? > - have someone from infra on standby during the next meeting to live > debug the issues Mostly agree on these ones, although I would share some more ideas in some lines :) > - have a fallback plan to have a proper meeting That's the difficult part. Should we use an audio-only conferencing system based on a PBX or something like it, instead? Probably audio-only streams are better optimized that way. Now back to my findings. I've invested some hours of my time (and I will do again this afternoon, if possible) on learning more on Jitsi and its guts. My primary source of information at the moment are this video: https://www.youtube.com/watch?v=Jj8a6ZRgehI And the documentation bits on the GitHub project: https://github.com/jitsi/jitsi-meet My first take on this is that cascading (in the sense of deploying multiple servers in different parts of the world) would not solve the participants number issue per se; it will obviously help with the general status of the conferencing system indeed. We have already pointed out the two most probable source of bottlenecks: * Network * CPU On the first point, guys at Jitsi recommend 10GE connectivity. This can be a problem, usually with VPSes this is something that is sold at high prices. Plus, they are leaving their video streams on, and they show flawless behavior with 15 people or something like it. I would expect that taking away video streams the numbers of participants could raise easily to 2.5 times (e.g. 35 people), but my take might be completely wrong (e.g. video streams are produced anyways just for the sake of deliver the audio streams). Second point: CPU. I have an additional input to this. Since I feel the most of the CPU would have been taken by the Videobridge module (the SFU, as pointed out by William), but not all of the CPU (jitsi-meet, prosody and jicofo modules will take resources as well), could be an idea to explore to separate the Videobridge module in a dedicated VM. Additionally, I don't think adding another Videobridge would be of any help: from my understanding, a single conference room is associated with one and only one videobridge. So for the CPU part what can be actioned to me is to take out the videobridge component in a new VM with the same hw capacities as the first one (we can scale it up as we scale down the main -meet machine, as it will take less resources). What do you think? Cheers, -- Emiliano Vavassori syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/website/ Privacy Policy: https://www.documentfoundation.org/privacy
[libreoffice-website] TDF Jitsi instance issues with 20+ people
Hi all, [I intend to involve all the Infra team here and I am not sure I am addressing this the right way. Please add the needed address yourselves or (better, please :) ) point the right addresses out.] During today's Public part of the Board of Directors meeting we had a lot of issues and I know most of you are already aware of it. We were connected fine until 20 people, at that point problems piled up (lags, disconnections, people not able to hear others, people not able to speak, jittering in the communications) and that was worsening towards 24 people connected; at that point we were forced to close the public part and get to the Board only for the private. My take on what happened is that we stuck hard on the "hardware" resources of the machine that hosts the instance. Someone also suggested hardware resources on the clients connected can be part of the issue. Could we please revise the entire idea on why the instance was brought out, what's the defined purpose of that, some technical information on it (like, hardware resources for the machine, how is Jitsi managed, etc) and its load during this meeting and understand its limits, with the goal of fixing it if ever possible in the next two weeks? I would like to discuss with all of you to find out and propose other solutions if needed, or keep the current one but see if we can further up the supported people (we expect another increase in participation in the next rounds, a good estimation could be 30 people). Thanks, regards, -- Emiliano Vavassori syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/website/ Privacy Policy: https://www.documentfoundation.org/privacy
