l10n process, en_US version, Help files

[sophi]

Hi all,

This mail is posted to the dev list and the l10n list, please follow up
on the l10n list.

I would like to open a discussion on the l10n workflow, the quality of
the en_US version and the Help files. All is linked and I would like to
discuss how we can improve the process here. I'm sure that having a
better understanding between the l10n process and the dev process should
help us to improve things So here is a proposal, it's a bit long,
sorry for that.

*Before updating Pootle:
- it's important for l10n team to know the approx load of work that will
be needed to achieve the whole work. Time between beta1 and rc1 is short
and that will help to better organize this time between translation and
proof reading.
- depending also on the type of changes, we could use different tools to
optimize the work.

*When the l10n start:
- we need a continuous communication and a planing of the updates made
in Pootle, those translating off line are always frightened to lose
something in the run.
- it's exhausting when you think you are over and to see a new bunch of
words coming. Knowing it in advance help to manage the time too

*After RC1 and l10n integration
- we need to know when integration is made after our fixes, there is
currently no communication on this

==> for these three items, I have asked today to Andras and Christian
how we can put that in place and where I can help them to do so, knowing
also that Christian is managing this part almost alone now.

*About the en_US overall quality
- the process to rely on the l10n team to fix the en_US version is ok,
even if it gives us extra work to understand what is meant before we
realized it's a mistake. So it's also error prone for all the translations.
- but that doesn't solve the several typos that already exist and that
are overlooked by the l10n team (e.g in the Character > Font Effect
dialog, there is Overline _c_olor and Underline _C_olor and this is the
same for several dialogs)
- that doesn't solve also the lack of universal vocabulary used in
several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or
Graphic/Picture/Image). I've nothing to propose here but to define a
glossary where developers could pick the good word but I'm not sure it
will be used

* About the help files
- I always wonder why there is a Help button on a new dialog when no
help file is appended
- more and more functions are undocumented or their help is obsolete. I
always think that an undocumented function is lost for the user and a
sad thing for a developer because his function will not be used as expected.
May be, but I don't know how heavy it would be for developers, the
solution would be to open an issue with a special tag like NF for each
new feature, with three lines about what the feature is supposed to
do. Searching on BZ with this special tag would allow to involve more
people in the loop to test it and document it.

Thanks for reading
Cheers
Sophie

[thackert]

Hello Sophie, *,
<snip>

I would like to open a discussion on the l10n workflow, the
quality of the en_US version and the Help files. All is linked and
I would like to discuss how we can improve the process here. I'm
sure that having a better understanding between the l10n process
and the dev process should help us to improve things So here is
a proposal, it's a bit long, sorry for that.

would this discussion not more suitable after the 4.2 release ;?

*Before updating Pootle:
- it's important for l10n team to know the approx load of work
that will be needed to achieve the whole work. Time between beta1
and rc1 is short and that will help to better organize this time
between translation and proof reading.

+1

<snip>

- it's exhausting when you think you are over and to see a new
bunch of words coming. Knowing it in advance help to manage the
time too

+1

<snip>

*About the en_US overall quality
- the process to rely on the l10n team to fix the en_US version is
ok, even if it gives us extra work to understand what is meant
before we realized it's a mistake. So it's also error prone for
all the translations. - but that doesn't solve the several typos
that already exist and that are overlooked by the l10n team (e.g
in the Character > Font Effect dialog, there is Overline _c_olor
and Underline _C_olor and this is the same for several dialogs)

Do not forget the double/triple/howmuchelse used mnemonics in the UI
...

- that doesn't solve also the lack of universal vocabulary used in
several dialogs (e.g Tab/Pane/Panel/Deck to name the same object
or Graphic/Picture/Image). I've nothing to propose here but to
define a glossary where developers could pick the good word but
I'm not sure it will be used

Yes, that would be really nice (especially, if we as translators
would get it as well ... ). It is really time consuming, what is
meant with word $X and then finding out, that word $Y was used on
other places ...

* About the help files
- I always wonder why there is a Help button on a new dialog when
no help file is appended

And me is wondering, why there is not only a help button but also a
help menu (as I am still a victim of
https://bugs.freedesktop.org/show_bug.cgi?id=72022, I am not sure,
if there should be any difference between the two ... ). Both
opens konqueror on my system, although I have installed the OLH ...

- more and more functions are undocumented or their help is
obsolete. I always think that an undocumented function is lost for
the user and a sad thing for a developer because his function will
not be used as expected. May be, but I don't know how heavy it
would be for developers, the solution would be to open an issue
with a special tag like NF for each new feature, with three lines
about what the feature is supposed to do. Searching on BZ with
this special tag would allow to involve more people in the loop to
test it and document it.

Yes, please I also would like to see a short description for new
function, that shortly explains it (and maybe a short example for it
documented there as well) ...
Thanks for your mail
Thomas.

[sophi]

Only answering your question: nope, because 4.3 is already on the radar,
so that would be great to have something in place for it

Cheers
Sophie

[thackert]

Hello Sophie, *,
[discussion about l10n workflow]

would this discussion not more suitable after the 4.2 release ;?

Only answering your question: nope, because 4.3 is already on the
radar, so that would be great to have something in place for it

O.K.
Thanks for your answer and have a nice evening
Thomas.

[qubit]

Hi all,

This mail is posted to the dev list and the l10n list, please follow up
on the l10n list.

I would like to open a discussion on the l10n workflow, the quality of
the en_US version and the Help files. All is linked and I would like to
discuss how we can improve the process here. I'm sure that having a
better understanding between the l10n process and the dev process should
help us to improve things So here is a proposal, it's a bit long,
sorry for that.

Hiya Sophie,
I've registered for the Pootle site, and I've started to poke around
on there. I'm not sure if there's anything I can do at that point in
the chain -- I guess I'll have to go up one level to the help and core
repos?

If there's anything specific I can do re: the en_US stuff, please let
me know. I've got a couple of airport layovers in my near future, so
I'll have a bit of time to spend

*Before updating Pootle:
- it's important for l10n team to know the approx load of work that will
be needed to achieve the whole work. Time between beta1 and rc1 is short
and that will help to better organize this time between translation and
proof reading.
- depending also on the type of changes, we could use different tools to
optimize the work.

I'm not exactly sure how we import data into pootle, but perhaps we
could set up some kind of web visualization tool to show the current
diff (in # of strings, # of words, etc..) between what's in the
upstream repos and what's in pootle. Would that be helpful?

*When the l10n start:
- we need a continuous communication and a planing of the updates made
in Pootle, those translating off line are always frightened to lose
something in the run.
- it's exhausting when you think you are over and to see a new bunch of
words coming. Knowing it in advance help to manage the time too

So basically
- better communication
- more lead-time before strings land in pootle

*After RC1 and l10n integration
- we need to know when integration is made after our fixes, there is
currently no communication on this

Perhaps documenting the process in some pages on the wiki would help
i10n better-understand how this works, and lead to some simple ways to
better communicate what's going on elsewhere back to the i10n teams.

*About the en_US overall quality
- the process to rely on the l10n team to fix the en_US version is ok,
even if it gives us extra work to understand what is meant before we
realized it's a mistake. So it's also error prone for all the translations.

I'm still getting my feet wet here, so I'm not quite as up to speed on
this process as you guys. It sounds like some of these issues are
rather nuanced, such that me being fluent in English isn't necessarily
going to help me track down problems much faster without some
additional context, right?

- but that doesn't solve the several typos that already exist and that
are overlooked by the l10n team (e.g in the Character > Font Effect
dialog, there is Overline _c_olor and Underline _C_olor and this is the
same for several dialogs)

What's our current workflow for solving those? Filing a bug, or?

- that doesn't solve also the lack of universal vocabulary used in
several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or
Graphic/Picture/Image). I've nothing to propose here but to define a
glossary where developers could pick the good word but I'm not sure it
will be used

Do we have a dialog with labels on all of the different parts,
indicating what nomenclature we're using to refer to each dialog or
component? Here's an example with a car dashboard:
http://12v.org/urs/EuroUrS6InstrumentClusterDiagram.jpg

Perhaps something like that would help the devs keep the naming consistent?

Cheers,
--R

[sophi]

Hi Robinson,

Hi all,

This mail is posted to the dev list and the l10n list, please follow up
on the l10n list.

I would like to open a discussion on the l10n workflow, the quality of
the en_US version and the Help files. All is linked and I would like to
discuss how we can improve the process here. I'm sure that having a
better understanding between the l10n process and the dev process should
help us to improve things So here is a proposal, it's a bit long,
sorry for that.

Hiya Sophie,
I've registered for the Pootle site, and I've started to poke around
on there. I'm not sure if there's anything I can do at that point in
the chain -- I guess I'll have to go up one level to the help and core
repos?

First, thanks for taking part of this and yes, given that en_US is
the source for all localization you have to fix it in the source. May be
Andras could give you more info here, it's one level to high for me

If there's anything specific I can do re: the en_US stuff, please let
me know. I've got a couple of airport layovers in my near future, so
I'll have a bit of time to spend

thanks a lot for your offer.

*Before updating Pootle:
- it's important for l10n team to know the approx load of work that will
be needed to achieve the whole work. Time between beta1 and rc1 is short
and that will help to better organize this time between translation and
proof reading.
- depending also on the type of changes, we could use different tools to
optimize the work.

I'm not exactly sure how we import data into pootle, but perhaps we
could set up some kind of web visualization tool to show the current
diff (in # of strings, # of words, etc..) between what's in the
upstream repos and what's in pootle. Would that be helpful?

Having the overall number of real words to translate (over the xml
changes or .ui port) would be great. I'm not sure I understand what you
have in mind with a web visualization tool

*When the l10n start:
- we need a continuous communication and a planing of the updates made
in Pootle, those translating off line are always frightened to lose
something in the run.
- it's exhausting when you think you are over and to see a new bunch of
words coming. Knowing it in advance help to manage the time too

So basically
- better communication
- more lead-time before strings land in pootle

yes, currently we are in the dark concerning numbers, updates,
integration, time for fixes.

*After RC1 and l10n integration
- we need to know when integration is made after our fixes, there is
currently no communication on this

Perhaps documenting the process in some pages on the wiki would help
i10n better-understand how this works, and lead to some simple ways to
better communicate what's going on elsewhere back to the i10n teams.

Yes, this is my idea, but I need input from Christian or Andras to write
the page

*About the en_US overall quality
- the process to rely on the l10n team to fix the en_US version is ok,
even if it gives us extra work to understand what is meant before we
realized it's a mistake. So it's also error prone for all the translations.

I'm still getting my feet wet here, so I'm not quite as up to speed on
this process as you guys. It sounds like some of these issues are
rather nuanced, such that me being fluent in English isn't necessarily
going to help me track down problems much faster without some
additional context, right?

I don't think you can do anything here, it's more on the developer side
before merging patches.

- but that doesn't solve the several typos that already exist and that
are overlooked by the l10n team (e.g in the Character > Font Effect
dialog, there is Overline _c_olor and Underline _C_olor and this is the
same for several dialogs)

What's our current workflow for solving those? Filing a bug, or?

Imho there is no formal workflow, or none I'm aware of. Filing a bug but
I don't know who will fix it, I think that most of the time Andras takes
action here.

- that doesn't solve also the lack of universal vocabulary used in
several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or
Graphic/Picture/Image). I've nothing to propose here but to define a
glossary where developers could pick the good word but I'm not sure it
will be used

Do we have a dialog with labels on all of the different parts,
indicating what nomenclature we're using to refer to each dialog or
component? Here's an example with a car dashboard:
http://12v.org/urs/EuroUrS6InstrumentClusterDiagram.jpg

Perhaps something like that would help the devs keep the naming consistent?

I don't know, this is why I need input from developers There are may
be guidelines for example the orders of the [Help] [OK] [Cancel]
buttons, but even here I'm not sure of the consistency, but I don't know
about a nomenclature of strings. I don't want to add processes or
constraints to developers, but more give them some references where they
can find quickly the good terms to use.

Cheers
Sophie

[stanislav.horacek]

Hi Sophie, all,

thank you very much for this initiative - it is really needed.
My few notes:

*After RC1 and l10n integration
- we need to know when integration is made after our fixes, there is
currently no communication on this

This can be found in the log of translations git module:
http://cgit.freedesktop.org/libreoffice/translations

- but that doesn't solve the several typos that already exist and that
are overlooked by the l10n team (e.g in the Character > Font Effect
dialog, there is Overline _c_olor and Underline _C_olor and this is the
same for several dialogs)

It would be worth to create a wiki page that summarizes all these rules - LO should use the Gnome rules (AFAIK), but there is a lot of specific issues: for example, descriptions of Calc functions in UI are quite messy because of different wording ("Returns...", "Calculates...", "Value of...") or parameter names (capitalization etc.).
Of course the UX team should be also involved.

* About the help files
- I always wonder why there is a Help button on a new dialog when no
help file is appended
- more and more functions are undocumented or their help is obsolete. I
always think that an undocumented function is lost for the user and a
sad thing for a developer because his function will not be used as expected.
May be, but I don't know how heavy it would be for developers, the
solution would be to open an issue with a special tag like NF for each
new feature, with three lines about what the feature is supposed to
do. Searching on BZ with this special tag would allow to involve more
people in the loop to test it and document it.

I would suggest a simpler approach without need for any additional input from developers. We can use release notes wiki pages where all new features are mentioned, create a list of new features and check if they are covered by the help.

Best regards,
Stanislav

[timar]

It is OK to fix new strings, also it is OK to fix obvious typos
anywhere. But we should refrain from re-phrasing old messages. It
would make a lot of unnecessary work for translators, and loss of
translation for unmaintaned languages. IMHO we have more important
things to do, than unify ("Returns...", "Calculates...", "Value
of...") or ("cannot", "couldn't", "could not") or whatever.

Best regards,
Andras

[timar]

There is the http://wiki.documentfoundation.org/ReleasePlan
Tag is usually made on Tuesday. So translation commit happens about a
day before that, let's say on Monday. So your fixes from Sunday will be
in. This is how it worked, when I did this job, and AFAIK Cloph does the
same.

Best regards,
Andras

[sophi]

Hi Andras, all,

*About the en_US overall quality
- the process to rely on the l10n team to fix the en_US version is ok,
even if it gives us extra work to understand what is meant before we
realized it's a mistake. So it's also error prone for all the translations.

Discissions in this mailing list usually helped to clarify the meaning.
Failing that, git log / git blame -- find out who the author was and ask
him or her. Translators are welcome to test new features, sometimes it
is obvious what a function does, despite the confusing UI text.

and sometimes not because you may also translate the product without
being an experienced user, or simply because you use Writer but not
Calc, etc...

- but that doesn't solve the several typos that already exist and that
are overlooked by the l10n team (e.g in the Character > Font Effect
dialog, there is Overline _c_olor and Underline _C_olor and this is the
same for several dialogs)

If it's overlooked by 60+ active translation teams + beta testers, then
probably it is not that much important. We can live with it.

Not sure, as Khaled said, it may be because the load of work on
translation is enough to not take care of other things.

* About the help files
- I always wonder why there is a Help button on a new dialog when no
help file is appended

Probably it is prescribed by some rule, e.g. Gnome HIG, that every
dialog must have a Help button. So dialog creator application puts it
there, and the developer leaves it there thinking that someone may write
a help page for it later.

Well, may be, but unfortunately the help page is never created.

- more and more functions are undocumented or their help is obsolete. I
always think that an undocumented function is lost for the user and a
sad thing for a developer because his function will not be used as expected.

As I wrote above, many functions/new dialogs are self-describing. I
hated to translate Gnome help 10 years ago, which was full of sentences
like this: "Click on Close button to close the dialog." So we need to
limit the scope here. It would be good, if you could give examples, what
needs further clarification in help.

They may be self describing for you, but not for most of our users. I've
collected some issues where the help needs to be amended or is missing,
but it would be better to have a general process and try to include more
people in it.

May be, but I don't know how heavy it would be for developers, the
solution would be to open an issue with a special tag like NF for each
new feature, with three lines about what the feature is supposed to
do. Searching on BZ with this special tag would allow to involve more
people in the loop to test it and document it.

The problem is that you cannot enforce any rule to developers. You can
write a mail to the list, newcomers will not see it. You can write wiki
pages, some people will not read it. You can ask people individually,
some will ignore you.

That I know
But I have an idea. What about prolonging the

string freeze date of help until the first bug fix release? That would
give developers/help authors/translators more time to concentrate on
documentation of new features. So we could say, with x.y.0 you get all
new features, and x.y.1 will come with updated help.

That's a good idea, but we still need help authors. I'm sure some people
will jump in, even earlier, if they only know where, hence the proposal
for a dedicated issue. As I said in another mail, I don't want to add
more processes, rules, etc. But there is some areas that impact more
than one team where it would be good to have some worflows.

Cheers
Sophie

[Christian_Lohmaier]

Hi *,

[...]
would this discussion not more suitable after the 4.2 release ;?

Only answering your question: nope, because 4.3 is already on the radar,
so that would be great to have something in place for it

And of course memory is still fresh, so people remember what bugged them :-))

ciao
Christian

[cloph]

Hi Sophie, *,

[...]
*Before updating Pootle:
- it's important for l10n team to know the approx load of work that will
be needed to achieve the whole work. Time between beta1 and rc1 is short
and that will help to better organize this time between translation and
proof reading.
- depending also on the type of changes, we could use different tools to
optimize the work.

Don't think this applies to a new minor version, as a new project is
created, the old one just renamed, so you immediately see in the new
project how much work is left. And only with that info you can decide
what meaningful way there is to minimize actual translation work.

*When the l10n start:
- we need a continuous communication and a planing of the updates made
in Pootle, those translating off line are always frightened to lose
something in the run.
- it's exhausting when you think you are over and to see a new bunch of
words coming. Knowing it in advance help to manage the time too

Yes, of course, and let me reiterate: I did not update any templates
in December. Whoever else did update them did so without prior notice.
I fully agree that before templates are updated l10n teams should be warned.
(but then again, I don't consider adding a new project as updating
templates in this regard - if the new data is wrong, just copy from
the old project, no loss, no additional work, no mixup with offline
translations)

*After RC1 and l10n integration
- we need to know when integration is made after our fixes, there is
currently no communication on this

For every build it is the same: Translations are extracted from pootle
on Tuesday and committed before tagging. Deadline for each tag is
Monday. So if you add your changes on Monday, all is fine, your
translations will be included. If you wait till Tuesday, your changes
might be missed.

The release schedule overview is available here:
https://wiki.documentfoundation.org/ReleasePlan
or more detailed for the next relevant releases:
https://wiki.documentfoundation.org/ReleasePlan/4.2#4.2.0_release
https://wiki.documentfoundation.org/ReleasePlan/4.1#4.1.5_release

There you see the dates for the relevant releases, and also in the
case of a new feature release the UI and string freeze dates.

If you look at the 4.2.0 schedule, you see that English string freeze
is next week (Monday, Dec 16) - so that is the week I did plan for
updating the templates in pootle.
I will grab the translations on Tuesday as for every build, (that way
there is a copy of the transations in the sourcecode, in case
something goes wrong with updating the templates), and after that
would add the new templates to pootle for l10nprojects to update.

Then l10n projects have a month to adapt to those late changes.

==> for these three items, I have asked today to Andras and Christian
how we can put that in place and where I can help them to do so, knowing
also that Christian is managing this part almost alone now.

Yes, 4.2.0 was the first time I did update the projects in pootle, and
I personally think it was not a huge desaster. There were two
stumbling stones:
1) update_against_templates aborting because of added/renamed files
2) lots of changes in help that only affect metadata (the xml-tag
attributes), not the actual translations

first was causing only a fraction of the changes to show up, leading
to the impression that almost nothing changes, and after that was
fixed, the second one caused a huge string count to be displayed,
probably making some translators think that suddenly their
translations were deleted or something, since after 1) they thought
they were almost finished.
2) was fixed with a script shortly afterwards, leaving only the real
changes to process.

Now what happened in December is a completely different story, esp.
that kk project did end up having Greek translation is still a
mystery, but not related to any updates.

*About the en_US overall quality
- [...]
- but that doesn't solve the several typos that already exist and that
are overlooked by the l10n team (e.g in the Character > Font Effect
dialog,

Those that have been reported on the list have been fixed by Andras or
me in the code - and people are very welcome to upload a patch to
gerrit themselves. (
https://wiki.documentfoundation.org/Development/gerrit )

- that doesn't solve also the lack of universal vocabulary used in
several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or
Graphic/Picture/Image). I've nothing to propose here but to define a
glossary where developers could pick the good word but I'm not sure it
will be used

Graphic/Picture/Image is for example one of the changes that have
already been somewhat unified for 4.2 - but yes, a
terminology/glossary doesn't really exist.

* About the help files
[...]
May be, but I don't know how heavy it would be for developers, the
solution would be to open an issue with a special tag like NF for each
new feature, with three lines about what the feature is supposed to
do.

Yes, this is a flaw by the committer/reviewers, who let the new
functionality pass into the code without making sure documentation is
created as well.

I guess it would help a lot if there is a group willing to write the
documentation when devs just say something like "I changed/added
functionality xy, please adapt the documentation to it"
Having devs write the documentation themselves doesn't necessarily
make it helpful

ciao
Christian

[timar]

Hi Christian,

Yes, 4.2.0 was the first time I did update the projects in pootle, and
I personally think it was not a huge desaster. There were two
stumbling stones:
1) update_against_templates aborting because of added/renamed files
2) lots of changes in help that only affect metadata (the xml-tag
attributes), not the actual translations

And one issue remained, there are more files in the database, than
actually needed, obsoleted files were not cleaned up (e.g. android/ folder).

Now what happened in December is a completely different story, esp.
that kk project did end up having Greek translation is still a
mystery, but not related to any updates.

And Greek has Kazakh fuzzies, as Dimitris reported yesterday: "Why in
the file of Greek sc/source/ui/src, I see so many Cyrillics with work
needed? Was there a mistake?"
When I maintaned Pootle, I was also scared about possible database
corruption, and since 2.5.0 we are experiencing mysterious server
errors, e.g. when changing permissions on folders. TDF pays a monthly
fee to Pootle devs for maintenance. I don't know, if you have worked
with them, Christian. (I sent you a mail about Pootle 2.5.1 and/or
Django update a few days ago.)

Cheers,
Andras

[sophi]

Hi Christian,

Hi Sophie, *,

[...]
*Before updating Pootle:
- it's important for l10n team to know the approx load of work that will
be needed to achieve the whole work. Time between beta1 and rc1 is short
and that will help to better organize this time between translation and
proof reading.
- depending also on the type of changes, we could use different tools to
optimize the work.

Don't think this applies to a new minor version, as a new project is
created, the old one just renamed, so you immediately see in the new
project how much work is left. And only with that info you can decide
what meaningful way there is to minimize actual translation work.

That doesn't apply to minor version, but for major version where we have
only few new strings and the rest is xml manipulations. I've discovered
that translation tools handle this very differently so knowing before
the new strings versus what we have already in our TM or commented in
the po files, etc... imho would help. But this may be simply not
possible for you, I'm not enough technical to know, which is why I ask

*When the l10n start:
- we need a continuous communication and a planing of the updates made
in Pootle, those translating off line are always frightened to lose
something in the run.
- it's exhausting when you think you are over and to see a new bunch of
words coming. Knowing it in advance help to manage the time too

Yes, of course, and let me reiterate: I did not update any templates
in December. Whoever else did update them did so without prior notice.
I fully agree that before templates are updated l10n teams should be warned.
(but then again, I don't consider adding a new project as updating
templates in this regard - if the new data is wrong, just copy from
the old project, no loss, no additional work, no mixup with offline
translations)

Yes, and again, this is discussion is by no mean to point somebody
mistake, but only to enhance our process and our communication.

*After RC1 and l10n integration
- we need to know when integration is made after our fixes, there is
currently no communication on this

For every build it is the same: Translations are extracted from pootle
on Tuesday and committed before tagging. Deadline for each tag is
Monday. So if you add your changes on Monday, all is fine, your
translations will be included. If you wait till Tuesday, your changes
might be missed.

The release schedule overview is available here:
https://wiki.documentfoundation.org/ReleasePlan
or more detailed for the next relevant releases:
https://wiki.documentfoundation.org/ReleasePlan/4.2#4.2.0_release
https://wiki.documentfoundation.org/ReleasePlan/4.1#4.1.5_release

There you see the dates for the relevant releases, and also in the
case of a new feature release the UI and string freeze dates.

If you look at the 4.2.0 schedule, you see that English string freeze
is next week (Monday, Dec 16) - so that is the week I did plan for
updating the templates in pootle.
I will grab the translations on Tuesday as for every build, (that way
there is a copy of the transations in the sourcecode, in case
something goes wrong with updating the templates), and after that
would add the new templates to pootle for l10nprojects to update.

Then l10n projects have a month to adapt to those late changes.

Ok, I'll add this to our l10n pages so new comers know how it works.

==> for these three items, I have asked today to Andras and Christian
how we can put that in place and where I can help them to do so, knowing
also that Christian is managing this part almost alone now.

Yes, 4.2.0 was the first time I did update the projects in pootle, and
I personally think it was not a huge desaster.

me too, be sure and thanks a lot for your work
There were two

stumbling stones:
1) update_against_templates aborting because of added/renamed files
2) lots of changes in help that only affect metadata (the xml-tag
attributes), not the actual translations

first was causing only a fraction of the changes to show up, leading
to the impression that almost nothing changes, and after that was
fixed, the second one caused a huge string count to be displayed,
probably making some translators think that suddenly their
translations were deleted or something, since after 1) they thought
they were almost finished.
2) was fixed with a script shortly afterwards, leaving only the real
changes to process.

ok, thank you for the details

Now what happened in December is a completely different story, esp.
that kk project did end up having Greek translation is still a
mystery, but not related to any updates.

*About the en_US overall quality
- [...]
- but that doesn't solve the several typos that already exist and that
are overlooked by the l10n team (e.g in the Character > Font Effect
dialog,

Those that have been reported on the list have been fixed by Andras or
me in the code - and people are very welcome to upload a patch to
gerrit themselves. (
https://wiki.documentfoundation.org/Development/gerrit )

My concern is for what is not reported by us (and hence, not reported at
all), I know that Andras and you are fixing very quickly what we
reported here or on the QA list.

- that doesn't solve also the lack of universal vocabulary used in
several dialogs (e.g Tab/Pane/Panel/Deck to name the same object or
Graphic/Picture/Image). I've nothing to propose here but to define a
glossary where developers could pick the good word but I'm not sure it
will be used

Graphic/Picture/Image is for example one of the changes that have
already been somewhat unified for 4.2 - but yes, a
terminology/glossary doesn't really exist.

And I'm not sure it will be used anyway, I don't have the solution
currently

* About the help files
[...]
May be, but I don't know how heavy it would be for developers, the
solution would be to open an issue with a special tag like NF for each
new feature, with three lines about what the feature is supposed to
do.

Yes, this is a flaw by the committer/reviewers, who let the new
functionality pass into the code without making sure documentation is
created as well.

I guess it would help a lot if there is a group willing to write the
documentation when devs just say something like "I changed/added
functionality xy, please adapt the documentation to it"
Having devs write the documentation themselves doesn't necessarily
make it helpful

lol, yes. I propose an issue because it's a tool used by developers and
it's easy to query for other teams, much more easy than gerrit and the
issue can be linked to the patch (or the other way round).

Cheers
Sophie

[stanislav.horacek]

Hi,

It is OK to fix new strings, also it is OK to fix obvious typos
anywhere. But we should refrain from re-phrasing old messages. It
would make a lot of unnecessary work for translators, and loss of
translation for unmaintaned languages. IMHO we have more important
things to do, than unify ("Returns...", "Calculates...", "Value
of...") or ("cannot", "couldn't", "could not") or whatever.

I just meant to use rules for new strings, not to make revolution in
current translations. At least not for now, when we are frustrated by all
the changes due to .ui conversion and when Pootle has no translation
memory. However, the current state is far from what you describe: we
resubmit translations for options pricing (first letter capitalized),
graphics changed to images, change in reset filter...

And I'm sorry, but volunteers can't be forced to do more important things -
they do what they like/are able to do; and it should be clearly said what
is desired and what isn't.

Best regards,
Stanislav

[matm]

Hi all

My grain of salt there. I strongly believe we need to cross-talk, so I go on cross-posting.

Hi Andras, all,

*About the en_US overall quality

Further discussed

- but that doesn't solve the several typos that already exist and that
are overlooked by the l10n team (e.g in the Character > Font Effect
dialog, there is Overline _c_olor and Underline _C_olor and this is the
same for several dialogs)

[...]

Not sure, as Khaled said, it may be because the load of work on
translation is enough to not take care of other things.

We have three steps here:
- Seeing the typo / obvious inconsistency
- Marking the typo
- Fixing the typo

* See : With a en-US ui, you can catch some during normal work
Else, you are in a chase for them (QA, l10n, someone ? ).

* Next step is to mark them.
When you are in a chase, you can organize stuff to avoid duplicate work and jot all references to, say, a wiki page or an etherpad, whatever fits
When you catch one on LO: what will make you go further ? Easiness. We need a simple process to submit. The counterpart is that we may have many false positives, so more filtering to do. Conclusion : either we provide a simple way to report a miss in the text because it may provide useful input, or we consider not having enough people to filter, and we limit ourselves to chases.

* And... fixing !
Easy hacks or l10n sessions to fix that are both valid choices. We may want to automate finding occurrences of text in the code. We began with fdo#39439, but further steps are required.

* About the help files
- I always wonder why there is a Help button on a new dialog when no
help file is appended

Probably it is prescribed by some rule, e.g. Gnome HIG, that every
dialog must have a Help button. So dialog creator application puts it
there, and the developer leaves it there thinking that someone may write
a help page for it later.

Well, may be, but unfortunately the help page is never created.

And who is this someone ?

BTW, I don't really know the workflow to provide some help content, but I think the developer creating a help button should at list input some draft so people have a start to improve (like we had some lengthy comments on usage in code before).
We may have a script to parse the code and find help links without targets, but to fight against obsolescence, we need people involved and scanning the help, or like typos an easy way to report.
We are more in a typewriting & review process than a l10n one, so maybe we need doc@ here.

- more and more functions are undocumented or their help is obsolete. I
always think that an undocumented function is lost for the user and a
sad thing for a developer because his function will not be used as expected.

As I wrote above, many functions/new dialogs are self-describing. I
hated to translate Gnome help 10 years ago, which was full of sentences
like this: "Click on Close button to close the dialog." So we need to
limit the scope here. It would be good, if you could give examples, what
needs further clarification in help.

They may be self describing for you, but not for most of our users. I've
collected some issues where the help needs to be amended or is missing,
but it would be better to have a general process and try to include more
people in it.

If I admit your example is quite useless, Andras, we have many not-at-all savvy users which actually needs the help, and the basic one, not the expert one. That is the hard stuff. I don't want to dive into tutorials in help, but a good explanantion and an example may help people figure how to use something or to determine if this something is what they are searching for.
Remember that we have many facilities in LibreOffice, and we don't know them all. So at one point you have to search for them. And here goes the help system.

May be, but I don't know how heavy it would be for developers, the
solution would be to open an issue with a special tag like NF for each
new feature, with three lines about what the feature is supposed to
do. Searching on BZ with this special tag would allow to involve more
people in the loop to test it and document it.

The problem is that you cannot enforce any rule to developers. You can

[...]

That I know
But I have an idea. What about prolonging the

string freeze date of help until the first bug fix release? That would

[...]

That's a good idea, but we still need help authors. I'm sure some people
will jump in, even earlier, if they only know where, hence the proposal
for a dedicated issue. As I said in another mail, I don't want to add
more processes, rules, etc. But there is some areas that impact more
than one team where it would be good to have some worflows.

We can have a start saying all contributore to libreoffice are nice
Then, we can ask for some information, like I said above, but I agree we need authors there.

I don't say it will be easy, and I don't want to be like a do-this-and-that. The above statements are just my view of what I think could help to improve ourselves on those points.

Thanks for your attention

Mat

[toki]

Thomas Hackert wrote:

would this discussion not more suitable after the 4.2 release ;?

An en_US L10N team should have been created back when TDF was setting up LibOP.

Whilst waiting is always optional, by setting up something now, there is a fairly good chance that the en_US version of LibO 4.3 won't contain the glaring spelling, grammer, vocabulary, and other errors that were found in LibO 4.0, and 4.1.

jonathon

[caolan]

One thing that we could with the new .ui file format is to confirm if
each dialog actually has a help entry for it. There is an easy hack at
https://bugs.freedesktop.org/show_bug.cgi?id=67350 to extract out the
new-format helpids from the help and determine if they actually exist.
That would weed out typos where the help gets detached from the thing it
documents.

Similarly someone could script if each new-format dialog has a help
entry and make a list of stuff that is missing help and turn those into
a list of tasks to document those things.

Another thing that could be automated is to generate a skeleton help
page from a new-format dialog. i.e. generate the help ids bookmarks for
the interactive widgets, buttons, checkboxes, etc. and have fill-me-in
headings and bodytext.

C.

[Tom_Davies1]

Hi
I am fairly sure the Documentation Team is NOT up to doing this but
perhaps with a little help they might be? They wont be able to do any
of the coding, however easy it is, but the skeleton help-page sounds
like something they might be really good at. They recently got into
doing the wiki-Faq so they might be less scared of working around
coding tags and such nowadays. Would it be a good idea to give them a
proposal of what might be required?
Regards from
Tom