Minutes of ESC call 2017-07-05

l10n
#1

Sorry for the extra work, but... :wink: :-*

-------- Weitergeleitete Nachricht --------

#2

BTW:

With "file for file" I meant the review process.

P.S. Please let the "<defaultinline/>" phrase string out of translation or remove it if you want.

Removal of it by ohallot is already in gerrit.

#3

Hi Sophia,

Sorry for the extra work, but... :wink: :-*

No problem, let see how we can try to find a compromise that could work
for you and for translators.

-------- Weitergeleitete Nachricht --------
Betreff:     Re: Minutes of ESC call 2017-07-05
Datum:     Sat, 7 Jul 2018 18:44:56 +0200
Von:     Sophia Schröder <sophia.schroeder@libreoffice.org>
Organisation:     LibreOffice.org
An:     libreoffice@lists.freedesktop.org

* Documentation (Olivier)

+ New help
         + Testing in bug hunting session tomorrow (installs)
         + Small corrections in XSLT filter
         + tweaks in CSS by fitoshido – people start contributing
     + Help contents
         + cosmetic refactor by SophiaS
         + Contents for [NatNum12] by Lazlo Nemetz
         + Contents fixes (ohallot, fitoshido)
* l10n (Sophie)
    + gave feedback to Olivier on reformat patches – cosmetics changes
      not ideal for our l10n volunteers
    + better to also have actual help content changes alongside

I am with you. Please see my minor cosmetical changes as they are intented:
A ground work for further improvements and easier work with the help
files themselves.
And it is planned as a "Long Term Project" to not flood translators with
minor changes at once.

Let me explain it in one phrase as an example:

"Press the Enter key." - In this form, the plain text will be displayed
to our user.

But hey, we have also at least two other forms of this sentence:

"Press the <emph>Enter</emph> key.", which will display the word "Enter"
in bold.

And there is "Press the <item type="keycode">Enter</item> key.", which
behaves like the second case for now.

But in the end, the last one let us play with more possibilities in css
styles, no? (I am not sure, just speculating).
I am thinking about an underlying background of a key, for example.

And yes, I am experimenting a bit here and there to find out best
solutions and practices.

So yes, carefull reviewings and criticisms are very welcome.

My proposal was to keep your work, but as part of a global rework of the
file, not as a unique change when it's about moving a period or some
spaces between two xml tags. Better, push the changes when a paragraph
or a sentence is modified or amended. That way there is no double work
for translators (or even triple if there is a typo in the new sentence
as it mays often happen due to the difficulty to work in the middle of
xml files).

And things like "<emph>Print </emph>icon" - l only say kerning and
spacing in the resulting text.

I would like to extend/expand help textes by the way, while also
reducing translation work by using the embedding feature instead of
translating the same sentence several times again, but honestly, I have
no clue how that works.

This could be difficult for translation because the meaning could be
different taking the context, grammar, gender and so on, into account.

I also changed my workflow to work file for file, hope that helps, at
least in my case for merge conflicts I cannot solve online, but also for
reviewing.

Maybe you could coordinate your work with others in the documentation
team and achieve the same work you are doing now but in the files they
are adding content to. That way, you continue working on what you want
and translators have only one time translation work on the same file.
Would you see that possible to organize with Olivier and would that be
convenient for you?

Cheers
Sophie

#4

Hello Sophie, *,

the big workload of my 1st round of changes have just landed in Pootle and I see the issues they caused.

Some of the the "improvements" I made turned out to not be needed/helpful at al,
others introduces new inconsistencies.
And there are some new mistakes not neccessarily caused by me, but now they are there.

My plan was to go through file for file in a more or less numerical order.

It seems to turn out not to be the best solution for the project.

If o.k., I could take the file(s) I just see a mistake in in Pootle. Would that helps?

Hi Sophia,

Sorry for the extra work, but... :wink: :-*

No problem, let see how we can try to find a compromise that could work
for you and for translators.

-------- Weitergeleitete Nachricht --------
Betreff:     Re: Minutes of ESC call 2017-07-05
Datum:     Sat, 7 Jul 2018 18:44:56 +0200
Von:     Sophia Schröder <sophia.schroeder@libreoffice.org>
Organisation:     LibreOffice.org
An:     libreoffice@lists.freedesktop.org

* Documentation (Olivier)

+ New help
         + Testing in bug hunting session tomorrow (installs)
         + Small corrections in XSLT filter
         + tweaks in CSS by fitoshido – people start contributing
     + Help contents
         + cosmetic refactor by SophiaS
         + Contents for [NatNum12] by Lazlo Nemetz
         + Contents fixes (ohallot, fitoshido)
* l10n (Sophie)
    + gave feedback to Olivier on reformat patches – cosmetics changes
      not ideal for our l10n volunteers
    + better to also have actual help content changes alongside

I am with you. Please see my minor cosmetical changes as they are intented:
A ground work for further improvements and easier work with the help
files themselves.
And it is planned as a "Long Term Project" to not flood translators with
minor changes at once.

Let me explain it in one phrase as an example:

"Press the Enter key." - In this form, the plain text will be displayed
to our user.

But hey, we have also at least two other forms of this sentence:

"Press the <emph>Enter</emph> key.", which will display the word "Enter"
in bold.

And there is "Press the <item type="keycode">Enter</item> key.", which
behaves like the second case for now.

But in the end, the last one let us play with more possibilities in css
styles, no? (I am not sure, just speculating).
I am thinking about an underlying background of a key, for example.

And yes, I am experimenting a bit here and there to find out best
solutions and practices.

So yes, carefull reviewings and criticisms are very welcome.

My proposal was to keep your work, but as part of a global rework of the
file, not as a unique change when it's about moving a period or some
spaces between two xml tags. Better, push the changes when a paragraph
or a sentence is modified or amended. That way there is no double work
for translators (or even triple if there is a typo in the new sentence
as it mays often happen due to the difficulty to work in the middle of
xml files).

I am not quite sure, what you mean. Can you explain it more, please?

And things like "<emph>Print </emph>icon" - l only say kerning and
spacing in the resulting text.

I would like to extend/expand help textes by the way, while also
reducing translation work by using the embedding feature instead of
translating the same sentence several times again, but honestly, I have
no clue how that works.

This could be difficult for translation because the meaning could be
different taking the context, grammar, gender and so on, into account.

Ah I see. So I do not longer bother. It is beyond my skills anyway for now.

I also changed my workflow to work file for file, hope that helps, at
least in my case for merge conflicts I cannot solve online, but also for
reviewing.

Maybe you could coordinate your work with others in the documentation
team and achieve the same work you are doing now but in the files they
are adding content to. That way, you continue working on what you want
and translators have only one time translation work on the same file.
Would you see that possible to organize with Olivier and would that be
convenient for you?

I wouldn't mind to improve my workflow in that way.
But I don't know how to achieve that, but open for discussions and hopefully working solutions in that manner.

#5

Hi Sophia,

Hello Sophie, *,

the big workload of my 1st round of changes have just landed in Pootle
and I see the issues they caused.

Some of the the "improvements" I made turned out to not be
needed/helpful at al,
others introduces new inconsistencies.
And there are some new mistakes not neccessarily caused by me, but now
they are there.

It's not easy to work in this area, so lets narrow what can be done in
respect of what you want to do.

My plan was to go through file for file in a more or less numerical order.

It seems to turn out not to be the best solution for the project.

If o.k., I could take the file(s) I just see a mistake in in Pootle.
Would that helps?

It depends of what you call a mistake. If it's only moving a space
between 2 xml tags, then no. If it's together with fixing a typo, adding
content or formatting, then it's ok. That maybe the part Olivier can
coordinate with you.

[jumping to your question :)]

So yes, carefull reviewings and criticisms are very welcome.

My proposal was to keep your work, but as part of a global rework of the
file, not as a unique change when it's about moving a period or some
spaces between two xml tags. Better, push the changes when a paragraph
or a sentence is modified or amended. That way there is no double work
for translators (or even triple if there is a typo in the new sentence
as it mays often happen due to the difficulty to work in the middle of
xml files).

I am not quite sure, what you mean. Can you explain it more, please?

I mean that formatting and adding content should happen at the same time
so translators don't have to work on the same file several times again
for the same version.

And things like "<emph>Print </emph>icon" - l only say kerning and
spacing in the resulting text.

I would like to extend/expand help textes by the way, while also
reducing translation work by using the embedding feature instead of
translating the same sentence several times again, but honestly, I have
no clue how that works.

This could be difficult for translation because the meaning could be
different taking the context, grammar, gender and so on, into account.

Ah I see. So I do not longer bother. It is beyond my skills anyway for now.

oki

I also changed my workflow to work file for file, hope that helps, at
least in my case for merge conflicts I cannot solve online, but also for
reviewing.

Maybe you could coordinate your work with others in the documentation
team and achieve the same work you are doing now but in the files they
are adding content to. That way, you continue working on what you want
and translators have only one time translation work on the same file.
Would you see that possible to organize with Olivier and would that be
convenient for you?

I wouldn't mind to improve my workflow in that way.
But I don't know how to achieve that, but open for discussions and
hopefully working solutions in that manner.

So let's discuss with Olivier who is organizing the work here, maybe he
will have some ideas on how to enhance the process and include you there.
I also have a question on the formatting added to the file, is this
documented somewhere? I recall the moment some years ago where several
<emph></emph> where removed and I would like to know what is the rule here.

Cheers
Sophie