Well, the double spaces problem ...
I have removed all occurences in the Slovenian help, and now I will be
forced to go through that again manually ... L10n teams/languages do not
have same errors, see, and this way we are spending time on things that we
might have fixed long ago ...

Besides the fuzzy mark gettext should obviously be extended with a
"source-string-changed-but-it-might-not-affect-your-existing-translation-because-it-was-a-minor-edit"
tag which should not lead to untranslated status of the string in code and
the existing translation should be pulled from git as still a valid one.

This tag could be called in short "check-translation" or
"minor-source-change" or something similar.

Is this feasible with the gettext developers?

Lp, m.

2018-04-08 12:01 GMT+02:00 Sophia Schröder <sophia.schroe...@libreoffice.org
>:

> 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.
>
> 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.
>
>
> 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 <mi...@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+unsubscr...@global.libreoffice.org
> Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-un
> subscribe/
> 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
>

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

Reply via email to