Hi Emiliano, *,
On Fri, May 19, 2023 at 10:33 PM Emiliano Vavassori
Il 19/05/23 12:13, Christian Lohmaier ha scritto:
To have translated sidebar buttons you
need to provide translated content in silverstipe backend on the
the "Sidebar Button" field labeled "Sidebar buttons, see
https://redmine.documentfoundation.org/issues/1023" the ticket shows
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.
No need for me here - it is treated as regular page content, so just
saving the file in the backend will do the trick.
(if the content box is empty, it defaults to the English sidebar, if
there is content, that will be used instead - there's no need to use
the button style, but since the css/html for that might not be obvious
the sample syntax for those is provided in the redmine ticket)
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.
While I don't know exactly why the strings were missing, at least now
the export did work as expected.
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
When I write manual it is not so bad as having to copy each string
manually, but to do some cleanup of the files. For example remove
entries with no/empty translation so that the content will not just
disappear and similar stuff.
And the strings completely missing from the old export/showing up in
only some just has been not reported/missed earlier - Last time when
German team mentioned the missing GPG strings I naturally only focused
on them, and those were there...
So automated mechanism wouldn't really have helped here.
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
It can be summarized as such: If it is not a simple page type, but for
example a page of type DownloadPage or DonatePage, then chances are
high that large parts of those come from weblate/are autogenerated.
everything else is is in silverstripe directly
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.
If you mean people maintaining localized websites? Nope, no fallback
for those, and I guess having the pages handled automatically / not
having an incentive to log in to the site to update it for each
release along with the content of the English page also not changing
often/at all didn't help in having active people. Basically you only
have to create a localized page once, and then don't have to care
If you mean backups of the translations: weblate stores them in a git
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?
Yes, so far the development on the sample site has been done with
hugo, but I currently don't know a concrete date, but I'd certainly
hope it will be completed this year/in the next months.
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.
Yes, and as written above: the steps are manual, but not overly
complex... And we didn't have any new NL-sites in quite a
while/everything is already settled in...
Thank you again so much for the answers and having unblocked the issue,
Thanks for bringing it to the list/to my attention - that is really
the only reason why it has been fixed, I wouldn't have noticed
So if there should be a lesson to be learned then it is not to wait
too long to complain :-)
To unsubscribe e-mail to: email@example.com
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy