Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


Hi,

Regarding adding the space between the first and the second index entry inside the bookmarks, I think it would still be okay to change it to but would cause too much noice for too little win (consistency), indeed.
So no need to spend more efforts in this. All I wanted to know. ;-)
It was just a random file I picked and submitted to gerrit to get a feedback about this kind of changes.
I did it also in other patches wherein I will revert that.

And I will also fix the other issues I caused in my patches regarding XML syntax of course, hoping the xmllint checker chloph wants to integrate will help me and others in this regards
so nobody needs to review XML mess in help related commits anymore.

Am 09.04.2018 um 17:36 schrieb Sophie:
Hi Sophia,
Le 08/04/2018 à 12:01, Sophia Schröder a écrit :
I experienced them in older versions of LibreOffice in German, where the
old behaviour were used.

I changed (and proofreaded, while at it) already our help in German with
the syntax:

<bookmark_value>blah; blubb</bookmark_value><boookmark_value>foo;
bar</bookmark_value>

So there should be correct.
I don't understand what you want to achieve here. The space between
'blah;' and 'blubb' is not needed, the help index is build as blah=first
level, blubb=second level of indentation.
See here for an explanation
https://wiki.documentfoundation.org/UI_and_Help_files_Content_Guide#.3Cbookmark_value.3E.3C.2Fbookmark_value.3E
I won't add any space because as I said it's a great way to recognize
that it's an index entry.
But I will have a closer look in the next days for examples.
I think the patches with this kind of changes in
can wait and lurk in gerrit meanwhile. ;-)

Others can be merge meanwhile,
b/c the double spaces appear in flowing text only.
There are a lot of double spaces added in sentences where it is real
spaces (and will have an incidence in the look and quality of the en_US
help), I think (I might be wrong) this is the a problem with the help
tool that should be corrected, or at least be removed before committing
the patch. I've absolutely no time to dedicate to it at the moment, but
if someone would like to have a look at it, it would be great.

Cheers
Sophie
Am 08.04.2018 um 11:43 schrieb Martin Srebotnjak:
Hi, Sophia,

I do not see these glitches in LibreOffice help. Can you send me a
screenshot?

Thanks, m.

2018-04-08 11:35 GMT+02:00 Sophia Schröder
<sophia.schroeder@libreoffice.org
:
Hi,

it causes visual glitches, like comma faults, at least in the old help
system.

So yes, I think so.

Assuming the most translation were done already correctly
it is also an opportunity to review own translations.

Otherwise there are just 2 clicks, no?

And it is not a long where it may "disturb" translators.
Once it is done, it is done. Except new strings of course.

And there don't come in a big bunch and I am also testing in the moment,
which are the best practices to get rid of some failures
and to make our help system and files more consistent.
I have no problems with abandoning my patches for good reasons.

It is a learning process for me too.

Am 07.04.2018 um 23:11 schrieb Martin Srebotnjak:

Hi,

just one example from Gerrit 4 hours ago:
"vector graphics;converting bitmaps"
was changed to:
"vector graphics; converting bitmaps"
See: https://gerrit.libreoffice.org/#/c/52546/2/source/text/
simpress/guide/vectorize.xhp

Is that "missing space" an error? Not. What does this change cause? It
causes 100+ translations of that string obsolete, fuzzy,
untranslated, not
shown in builds ... And 100+ localizers must again localize, check, edit
this same string ...

Is this kind of editing/"cleaning-up" of help really useful/desired?
Not.

Lp, m.

2018-04-07 22:01 GMT+02:00 Martin Srebotnjak <miles@filmsi.net>:

Hi,

And now the Babilon tower is open to all ...

For years I was asking for a kind of a review process for all new
strings
in UI/help and for the editing process. So someone overlooks all the
changes going in and stops the ones that seem unfit (in langague or
technical sense), thus reducing the repetitive editing of same strings.

Instead, now there is a possibility to edit everything even more
"easily", with even less thinking about it before it is done.

So now we might see a surge in help changes that make many l10n
projects
quite vulnerable, and most probably several edits of same strings in
a row
(a documenter reminding oneself that another thing should be added or
changed or edited, after it is already featured in git).

Hopefully, this function is limited to master, because if this is
available in "stable" versions, this will lead to havoc ...

Lp, m.

--
Regards / Mit freundlichen Grüßen

Sophia Schröder
---
German Language Team
LibreOffice.org
IRC: SophiaS




--
Regards / Mit freundlichen Grüßen

Sophia Schröder
---
German Language Team
LibreOffice.org
IRC: SophiaS


--
To unsubscribe e-mail to: l10n+unsubscribe@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/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.