![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Hi,
(not going to rant about all the 7000+ unnecessary fuzzies and false positive checks - but still...)
There is a weird string in LibreOffice master – UI --> extensions/messages.po --> Unit #137750341
Seems there's no translatable text and thus no translation possible.
Can someone check in their language?
Sveinn í Felli
Hi Sveinn
It seems like the empty sting was marked for translation:
#define RID_UPDATE_BUBBLE_DOWNLOADING
NC_("RID_UPDATE_BUBBLE_DOWNLOADING", "")
https://opengrok.libreoffice.org/xref/core/extensions/inc/strings.hrc#320
This RID_UPDATE_BUBBLE_DOWNLOADING was an empty string before the gettext
migration too:
https://cgit.freedesktop.org/libreoffice/core/commit/extensions/source/update/check/updatehdl.src?id=00657aef09d854c74fb426a935a3e8b1fc390bb0
But I think now the gettext framework would retrieve the mo file header
here, which is probably not the expected behavior.
Could you file a bug report please?
Regards
Gabor
Hi Gabor;
There are more creepy things circulating:
For example in LibreOffice master – UI --> wizards/source/resources.po --> Unit #137767072 I get this in the downloaded PO-file:
#. zRGEs
#: resources_en_US.properties
#, fuzzy
msgctxt ""
"resources_en_US.properties\n"
"RID_COMMON_21\n"
"property.text"
msgid ""
"The wizard could not be run, because important files were not found.\\n"
"Under 'Tools - Options - %PRODUCTNAME - Paths' click the 'Default' button to "
"reset the paths to the original default settings.\\n"
"Then run the wizard again."
msgstr ""
"Ekki tókst að keyra leiðarvísinn, þar sem mikilvægar skrár fundust ekki.\n"
"Farðu í 'Verkfæri - Valkostir - %PRODUCTNAME - Slóðir' smelltu á "
"'Sjálfgefið' hnappinn til að endursetja slóðirnar á upprunalegar stillingar.\n"
"Keyrðu svo aftur leiðarvísinn."
You see the double backslash in the newline entities, compared to the "normal" ones in my older translation. There's a bunch of similar issues; possibly my download got somehow fubar-ed, will try again later.
But possibly this is a more serious server-side matter!
Will file a bug once someone else confirms the behaviour for other languages.
Best regards,
Sveinn í Felli
Þann fös 6.okt 2017 08:52, skrifaði Gabor Kelemen:
Hi,
you are correct, that string is now buggy, but it is as such some time in
the 6.0/master ...
Lp, m.
Forgot to say that in Pootle the string is normal (without the extra-backslash).
Sveinn
Hi Sveinn
I see that string in git has only normal \n sequences:
https://cgit.freedesktop.org/libreoffice/core/tree/wizards/source/resources/resources_en_US.properties#n46
Just like on the Pootle UI.
But the downloaded file contains double backslashes for Hungarian too.
So this one may be a Pootle issue, not a source code one.
Regards
Gabor
https://cgit.freedesktop.org/libreoffice/core/commit/?id=029f2fdc
What the fucking shit happens again and again release to release? In
Russian we get 7_540 items to translate and most of them are tinkering
with English source items, that doesn't change anything in translated
items, but again, again, and AGAIN we need to restore by hands old
translations for new sources.
Please, please, PLEASE make English-to-English translation and play
with spaces and capital letters there...
Hi all,
Hi Sveinn
I see that string in git has only normal \n sequences:
https://cgit.freedesktop.org/libreoffice/core/tree/wizards/source/resources/resources_en_US.properties#n46Just like on the Pootle UI.
But the downloaded file contains double backslashes for Hungarian too.
So this one may be a Pootle issue, not a source code one.
I'll check with Christian next week when we will be in Rome and will
give you feedback on that.
Cheers
Sophie
Hello,
With the master update Frisian lost 50% of it's translations.
That can't be right.
I see a lot of languages only loose 10%
Greetings
Berend Ytsma
Frisian Translator
https://cgit.freedesktop.org/libreoffice/core/commit/?id=029f2fdc
What is your point?
What the fucking shit happens again and again release to release?
Watch your mouth. Nobody has put a gun down your throat to oblige you
to contribute.
Russian we get 7_540 items to translate and most of them are tinkering
with English source items, that doesn't change anything in translated
items, but again, again, and AGAIN we need to restore by hands old
translations for new sources.
You realize that Cloph fixes this behind the scenes every six months, right?
Please, please, PLEASE make English-to-English translation and play
with spaces and capital letters there...
You realize that this suggestion makes no sense whatsoever?
Adolfo
Hi Adolfo
https://cgit.freedesktop.org/libreoffice/core/commit/?id=029f2fdc
What is your point?
What the fucking shit happens again and again release to release?
Watch your mouth. Nobody has put a gun down your throat to oblige you
to contribute.
Russian we get 7_540 items to translate and most of them are tinkering
with English source items, that doesn't change anything in translated
items, but again, again, and AGAIN we need to restore by hands old
translations for new sources.
You realize that Cloph fixes this behind the scenes every six months, right?
Please, please, PLEASE make English-to-English translation and play
with spaces and capital letters there...
You realize that this suggestion makes no sense whatsoever?
Please all, calm down, we will look after what bugs next with Christian.
There has been changes with gettext, others with UX, we will sort out what
should be automated and what can't. As Adolfo said there won't be EN to EN
translation however. But please think that LO needs to evolve and we need
to adapt our process too, meaning that we can make mistakes together with
having to redo some work.
I'm a volunteer like you on this so be sure that I evaluate what commitment
it asks.
Cheers
Sophie
Hi,
https://cgit.freedesktop.org/libreoffice/core/commit/?id=029f2fdc
What is your point?
It is very simple.
As I can see, Pootle has 135 languages now and some teams work offline.
If someone makes ONLY ONE cosmetic change in translatable strings,
everyone of 135 language teams should adopt this change.
If someone makes a bunch of cosmetic changes (for ex. change
register, change spaces, add colons, remove colons -- I remember all
of them), everyone of 135 teams shold working hard to restore what was
alredy done.
So, what changed with this and like this commits?
1)
diff --git a/sc/inc/scfuncs.hrc b/sc/inc/scfuncs.hrc
index b1b64d2..b3a231f 100644
--- a/sc/inc/scfuncs.hrc
+++ b/sc/inc/scfuncs.hrc
- NC_("SC_OPCODE_GET_DATE", "year"),
+ NC_("SC_OPCODE_GET_DATE", "Year"),
- NC_("SC_OPCODE_GET_DATE", "month"),
+ NC_("SC_OPCODE_GET_DATE", "Month"),
- NC_("SC_OPCODE_GET_DATE", "day"),
+ NC_("SC_OPCODE_GET_DATE", "Day"),
- NC_("SC_OPCODE_GET_DATE_VALUE", "text"),
+ NC_("SC_OPCODE_GET_DATE_VALUE", "Text"),
- NC_("SC_OPCODE_GET_DIFF_DATE_360", "Date_1"),
+ NC_("SC_OPCODE_GET_DIFF_DATE_360", "Date 1"),
- NC_("SC_OPCODE_GET_DIFF_DATE_360", "Date_2"),
+ NC_("SC_OPCODE_GET_DIFF_DATE_360", "Date 2"),
... and so on ...
2) Before this in Pootle:
msgid "year"
msgstr "год"
msgid "month"
msgstr "месяц"
msgid "day"
msgstr "день"
msgid "text"
msgstr "текст"
...
3) After this in Pootle:
msgid "Year"
msgstr ""
msgid "Month"
msgstr ""
msgid "Day"
msgstr ""
msgid "Text"
msgstr ""
...
4) Than I need to translate again:
msgid "Year"
msgstr "год"
msgid "Month"
msgstr "месяц"
msgid "Day"
msgstr "день"
msgid "Text"
msgstr "текст"
...
5) The final of story is
-msgid "year"
+msgid "Year"
msgstr "год"
-msgid "month"
+msgid "Month"
msgstr "месяц"
-msgid "day"
+msgid "Day"
msgstr "день"
-msgid "text"
+msgid "Text"
msgstr "текст"
...
Is it really the Big Deal and all 135 teams need roll up their sleeves
to fix anyone irresponsible whim?
Please, please, PLEASE make English-to-English translation and play
with spaces and capital letters there...You realize that this suggestion makes no sense whatsoever?
Why not? Assign any unused language code for source and "en" for translation.
Hello,
>> https://cgit.freedesktop.org/libreoffice/core/commit/?id=029f2fdc
> What is your point?
It is very simple.
As I can see, Pootle has 135 languages now and some teams work offline.
If someone makes ONLY ONE cosmetic change in translatable strings,
everyone of 135 language teams should adopt this change.
As someone who translates practically alone for my language (mainly
stealing from my sleep), I agree that this is far from effective use of
volunteers’ often very scarce spare time. Saying ‘You’re volunteers so if
you don’t want to put up with 
, we’ll wait for someone who does’
doesn’t seem the best stance to take.
On the other hand, I’m also a stickler for correct typography, perfectly
composed layouts and such things and I think that ‘cosmetic’ changes often
go a long way to make a product appear much more professional and enjoyable
to work with.
>> Please, please, PLEASE make English-to-English translation and play
>> with spaces and capital letters there...
>
> You realize that this suggestion makes no sense whatsoever?Why not? Assign any unused language code for source and "en" for
translation.
This seems like an attractive option but it has problems of its own (like:
when looking at the source, you will never be sure how the actual UI looks
like; many teams may actually want to implement some of the changes made to
the ‘English translation’ but they will not be notified of them and will
have to periodically search for such, etc.).
OTOH, setting that particular solution aside, I’m sure that other things
can be done to somewhat improve the situation. For example, couldn’t some
mechanism be implemented to explicitly mark certain changes as ‘small’ or
‘cosmetic’ so that the translations in Pootle are just marked as ‘Needs
work’ instead of right out deleting them? Or even better, add a new status
specifically meaning ‘Cosmetic change’ that allows re-confirming the
existing translations en masse if the changes are irrelevant to them?
Best regards,
Mihail Balabanov
Þann 2017-10-06 09:57, Gabor Kelemen reit:
But the downloaded file contains double backslashes for Hungarian too.
So this one may be a Pootle issue, not a source code one.
Those strings (total of 6) did in previous version have [LF] newline symbols, which for some reason changes to '\\n' entities in Pootle. But uploading the file back to Pootle with normal '\n' entities in the translations *does* work, validations tests don't complain (but my Lokalize does).
So this is more of a strange quirk than a malfunction.
Regards,
Sveinn
Hello,
https://cgit.freedesktop.org/libreoffice/core/commit/?id=029f2fdc
What is your point?
It is very simple.
As I can see, Pootle has 135 languages now and some teams work offline.
If someone makes ONLY ONE cosmetic change in translatable strings,
everyone of 135 language teams should adopt this change.As someone who translates practically alone for my language (mainly
stealing from my sleep), I agree that this is far from effective use of
volunteers’ often very scarce spare time. Saying ‘You’re volunteers so if
you don’t want to put up with
doesn’t seem the best stance to take.On the other hand, I’m also a stickler for correct typography, perfectly
composed layouts and such things and I think that ‘cosmetic’ changes often
go a long way to make a product appear much more professional and enjoyable
to work with.Please, please, PLEASE make English-to-English translation and play
with spaces and capital letters there...You realize that this suggestion makes no sense whatsoever?
Why not? Assign any unused language code for source and "en" for
translation.This seems like an attractive option but it has problems of its own (like:
when looking at the source, you will never be sure how the actual UI looks
like; many teams may actually want to implement some of the changes made to
the ‘English translation’ but they will not be notified of them and will
have to periodically search for such, etc.).OTOH, setting that particular solution aside, I’m sure that other things
can be done to somewhat improve the situation. For example, couldn’t some
mechanism be implemented to explicitly mark certain changes as ‘small’ or
‘cosmetic’ so that the translations in Pootle are just marked as ‘Needs
work’ instead of right out deleting them? Or even better, add a new status
specifically meaning ‘Cosmetic change’ that allows re-confirming the
existing translations en masse if the changes are irrelevant to them?
Sometimes 'cosmetic' change could mean a difference. To me is indicative if string is 1) in all caps, if 2) first letter is capitalized and if 3) all letters are lowercased.
It's hard to mark what is cosmetic change from what was badly written before and now is corrected. Fixing bad language in template is a must and should not be optional.
That 'Month' ~ 'month' example may not make difference for Cyrillic scripts but Latin scripts can and should change translation accordingly.
No translation should be removed. Whatever changes in original string, mark translation as fuzzy and leave (old) translation in there.
Maybe there are volunteers who can make a script for Cyrillic writing system which could read trough po files, convert strings to lowercase, compare that to (Cyrillic) translation and change what needed if there is a match. Maybe this could work for some other writing systems/scripts.
If 'cosmetic' changes need to be: better in one-word string then in thous wrapping in two or three lines.
Kruno
Hi all,
Hello,
https://cgit.freedesktop.org/libreoffice/core/commit/?id=029f2fdc
What is your point?
It is very simple.
As I can see, Pootle has 135 languages now and some teams work offline.
If someone makes ONLY ONE cosmetic change in translatable strings,
everyone of 135 language teams should adopt this change.As someone who translates practically alone for my language (mainly
stealing from my sleep), I agree that this is far from effective use of
volunteers’ often very scarce spare time. Saying ‘You’re volunteers so if
you don’t want to put up with
doesn’t seem the best stance to take.On the other hand, I’m also a stickler for correct typography, perfectly
composed layouts and such things and I think that ‘cosmetic’ changes
often
go a long way to make a product appear much more professional and
enjoyable
to work with.Please, please, PLEASE make English-to-English translation and play
with spaces and capital letters there...You realize that this suggestion makes no sense whatsoever?
Why not? Assign any unused language code for source and "en" for
translation.This seems like an attractive option but it has problems of its own
(like:
when looking at the source, you will never be sure how the actual UI
looks
like; many teams may actually want to implement some of the changes
made to
the ‘English translation’ but they will not be notified of them and will
have to periodically search for such, etc.).OTOH, setting that particular solution aside, I’m sure that other things
can be done to somewhat improve the situation. For example, couldn’t some
mechanism be implemented to explicitly mark certain changes as ‘small’ or
‘cosmetic’ so that the translations in Pootle are just marked as ‘Needs
work’ instead of right out deleting them? Or even better, add a new
status
specifically meaning ‘Cosmetic change’ that allows re-confirming the
existing translations en masse if the changes are irrelevant to them?Sometimes 'cosmetic' change could mean a difference. To me is indicative
if string is 1) in all caps, if 2) first letter is capitalized and if 3)
all letters are lowercasedIt's hard to mark what is cosmetic change from what was badly written
before and now is corrected. Fixing bad language in template is a must
and should not be optional.That 'Month' ~ 'month' example may not make difference for Cyrillic
scripts but Latin scripts can and should change translation accordingly.
I agree with you that 'cosmetic' is not easy to define. And if you look
at the changes, sometimes it's a capital, sometimes a capital and a
space, sometime it's all caps, sometime a real change, so difficult to
script either or only for a handful of strings.
Cheers
Sophie
Suggestion from Krunose looks a good compromise::
"No translation should be removed. Whatever changes in original string, mark translation as fuzzy and leave (old) translation in there. "
What about that?
diego
Hi *,
Suggestion from Krunose looks a good compromise::
"No translation should be removed. Whatever changes in original string, mark
translation as fuzzy and leave (old) translation in there. "What about that?
that also is the case, in the from of obsolete strings, just that the
not-used strings are not exported from pootle webinterface, but only
in on-disk files. However as gettext migration changed
filenames/merged multiple ones into a messages.po, this is not true
for all files in the export - but for those cases you have the libo54
projects - that is what master was before it was updated - so no need
to worry about having lost translations or not being able to access
them.
ciao
Christian