English videos in help files

Hi all,

Some videos have been embedded in the help files.
As it's forbidden by law to provide help on a product in a foreign
language in France (and it may be the case in other countries), if we
don't translate them, we just put LibreOffice at risk in all the public
sector in France.

Could it be possible to ask for translation of these videos before they
are embedded in the help? or otherwise have the possibility to disable
the video completly?
What is the process to have them translated in the string, i.e. what
elements in the string need to be modified?

example:
Context: youtubevideos.xhp par_ytvideosample help.text
Locations: youtubevideos.xhp
T8mrB
https://help.documentfoundation.org/text/shared/06/youtubevideos.xhp
<object data="https://www.youtube-nocookie.com/embed/YHBve8v13VY"
id="vid_id61521568603544" type="video/youtube" width="560" height="315"/>

Thanks in advance
Cheers
Sophie

Hi, all,

Could it be possible to ask for translation of these videos before they
are embedded in the help? or otherwise have the possibility to disable
the video completly?

+10000000

Please, documentation writers and project leaders, try to understand there
might be l10n issues with introducing fanciful features like this without
any consultation with l10n teams ... Is it so hard to communicate in
advance the wonderful features you are preparing and to check out if they
present any trouble to l10n teams and how to go about those in advance?

Lp, m.

Hi all,

Some videos have been embedded in the help files.
As it's forbidden by law to provide help on a product in a foreign
language in France (and it may be the case in other countries), if we
don't translate them, we just put LibreOffice at risk in all the public
sector in France.

Hello Sophie,
Even if there are subtitles available in french?

Could it be possible to ask for translation of these videos before they
are embedded in the help? or otherwise have the possibility to disable
the video completly?
What is the process to have them translated in the string, i.e. what
elements in the string need to be modified?

example:
Context: youtubevideos.xhp par_ytvideosample help.text
Locations: youtubevideos.xhp
T8mrB
https://help.documentfoundation.org/text/shared/06/youtubevideos.xhp
<object data="https://www.youtube-nocookie.com/embed/YHBve8v13VY"
id="vid_id61521568603544" type="video/youtube" width="560" height="315"/>

Thanks in advance
Cheers
Sophie

ByeBye :slight_smile:

> Hi all,
>
> Some videos have been embedded in the help files.
> As it's forbidden by law to provide help on a product in a foreign
> language in France (and it may be the case in other countries), if we
> don't translate them, we just put LibreOffice at risk in all the public
> sector in France.

Hello Sophie,
Even if there are subtitles available in french?

I need to check if that already happened in court. Danone was the last
condamned that I'm aware of, but in any case that gives a way of pressure
in decision process that we don't need at all...

>
> Could it be possible to ask for translation of these videos before they
> are embedded in the help? or otherwise have the possibility to disable
> the video completly?
> What is the process to have them translated in the string, i.e. what
> elements in the string need to be modified?
>
> example:
> Context: youtubevideos.xhp par_ytvideosample help.text
> Locations: youtubevideos.xhp
> T8mrB
> https://help.documentfoundation.org/text/shared/06/youtubevideos.xhp
> <object data="https://www.youtube-nocookie.com/embed/YHBve8v13VY"
> id="vid_id61521568603544" type="video/youtube" width="560" height="315"/>
>
>
> Thanks in advance
> Cheers
> Sophie

ByeBye :slight_smile:

??
Cheers
Sophie

Why on earth are there videos in the help files?
That smacks of being a Section 508 violation.

jonathon

> Some videos have been embedded in the help files.

Why on earth are there videos in the help files?
That smacks of being a Section 508 violation.

Could you elaborate on this, BTW I'm sure Olivier didn't want to make
wrong but didn't realised the consequences. We need to enhance the help
files, I'm only sad that we are not part of the discussion when we are
highly concerned.

Cheers
Sophie

Why on earth are there videos in the help files?
That smacks of being a Section 508 violation.
Could you elaborate on this,

_Section 508_ is a US Law.

This is the federal regulation (^1) that requires government agencies,
and organizations with government contracts, to make _everything_
accessible to those with disabilities. ADA is a different law in the
United States, and it applies everywhere.

For a blind person, Audio-Captioning of a video, is a "reasonable
accommodation".
For a deaf person, Close-Captioning of a video is a "reasonable
accommodation".
For the deaf-blind, neither of those options are usable. What does work
is a transcript of both the audio-captioning and the closed-captioning,
but even that is generally considered to be little more than a work-around.

Is an audio-captioned transcript available?
Is a closed-captioned transcript available?

_If_ both of those are available, and integrated into one document,
then, if that was placed within the video, such that a deaf-blind person
could read it, it _might_ be Section 508 compliant.

Audio-captioning takes a long time. Budget one minute for each second in
the video. A five minute video would take 300 minutes to audio-caption.

BTW I'm sure Olivier didn't want to make wrong but didn't realized the consequences.

Section 508 is the type of regulation that nobody pays attention to,
unless they have a11y requirements.

I wouldn't be at all surprised if the video fails legal criteria in
Canada, for a very different set of reasons --- not locally produced.

We need to enhance the help files,

True.

Several times this year, I've started to write documentation, but it is
a huge task, that feels utterly overwhelming. Even breaking it down into
sub-tasks of sub-tasks of sub-tasks has an air of intimidation to it.

(About a year ago I concluded that the only way forward, was to throw
away all of the existing documentation, and rewrite everything from
scratch, because so much had changed, and the future promised even
bigger changes, with even less advance notice. Shortcuts that worked in
4.0 don't work in 6.0. Functionality that was present in 4.0 doesn't
exist in the 6.0.3 daily build. OTOH, one can do things in the 6.0.3
daily build that aren't doable in 5.x.)

I'm only sad that we are not part of the discussion when we are highly concerned.

That probably has as much to do with where and when the discussions are
held, as anything else.

Oliver is pretty good about providing the agenda, along with the date,
time, and place of the Documentation Team Meetings. EG: 2018-04-25 19:00
CET https://meet.jit.si/tdfdocteam agenda at
https://pad.documentfoundation.org/p/documentation

^1: Technically, it only applies to the federal government, and agencies
and organizations that have a contract with the federal government. On a
practical level, it also applies to state, county, and local government,
and organizations that have contracts with them.

jonathon

Jonathon,

>I'm only sad that we are not part of the discussion when we are highly
concerned.

That probably has as much to do with where and when the discussions are
held, as anything else.

Oliver is pretty good about providing the agenda, along with the date,
time, and place of the Documentation Team Meetings. EG: 2018-04-25 19:00
CET https://meet.jit.si/tdfdocteam agenda at
https://pad.documentfoundation.org/p/documentation

you miss the point. Changing help (documentation project) and UI (UX
project) is not a self-enclosed thing. This is one of the biggest open
source projects and changes in code (and UI and documentation) affect not
only many community members participating in the project on different
tasks, but millions of users. So we do need to copy or thoroughly adapt
some of the "corporate" workflow magic and make this process a road to
success, not to chaos.

Those teams can and should discuss its "structural", "perspective" changes
with the l10n teams. So no, all localizers should not join those two
projects and their jitsi sessions, but there must be a workflow where such
changes, when already thought through by its native team, get discussed
with l10n teams (who are not just localizers, translators, but in most
cases promoters of LO in their countries/languages/cultures and can offer a
lot of advice what might not be good for their language/cultural
environment/law requirements) - before they get introduced. So we need such
a forum/discussion point in development process.

I often remember the OOo days where every upcoming bigger feature had a
webpage (a kind of a wiki page in the Sun web subworld) made by the
developers, where they wrote about what they will be doing, why that is
needed, how they intend to do it and there was also a screenshot of a
mock-up or final UI window etc. This way a feature could be discussed with
others before a lot of hard work was being done and people reading it could
improve ideas and goals and that is why those features did not need so much
polishing later.

This iterative method of trial by error in the LO development is not a
problem in itself, if this project would not need localization and if there
would not be millions of users (i.e. with menus changing all the time in
the last few major releases and documentation hardly following them all) -
but all this iterative changing (that does lead to better and better
results, no doubt about it) in the end hits the l10n teams and makes their
members feel like Sisyphus.

Lp, m.

It is not appropriate to have lots of amateur legal speculation on this
list.
Please, don't discuss these issues here.

If you have a genuine concern around a legal issue please setup a call
with Simon or Eike who are responsible for legal topics on the board,
please provide only the briefest of rational for such a call.

Thanks.

Marina

I'm only sad that we are not part of the discussion when we are highly concerned.

That probably has as much to do with where and when the discussions are held, as anything else.

you miss the point. Changing help (documentation project) and UI (UX project) is not a self-enclosed thing.

One of the vices of agile development is that documentation is
considered to be, at best, unnecessary. This applies for both developer
documentation, and user documentation.

Whilst the theory is that Agile Development has the following for End
User Documentation Creation:

* using a topic-oriented approach such as the Darwin Information Typing
Architecture (DITA) or Information MappingTM
* leveraging user stories to produce task-oriented documentation
* applying minimalist principles
* participating as an active team member

the reality is that the usual Agile Development creed on end user
documentation is _They Ain't Gonna Read It So Why Bother Writing It_.

This is one of the biggest open source projects and changes in code (and UI and documentation) affect not only many community members participating in the project on different tasks, but millions of users.

The other part of the equation, is that there were/are features and
capabilities in LibO that virtually nobody other than the original
developer knows exist. Features that never made their way into any
user-documentation, and only got one line in a developer synopsis.

By way of example, which version of Logo is embedded within LibO?

Only slightly more esoteric is which version of R does LibO have hooks
for? (Who needs VBA when you've got R?)

Now wondering if the Flight Simulator game was removed from LibO.

So we do need to copy or thoroughly adapt some of the "corporate" workflow magic and make this process a road to success, not to chaos.

Sun practiced waterfall development, in which specifications for
everything were written out in advance.

TDF practices agile development, in which nothing is specified until
after delivery.

The adoption of these models reflect what was considered to be "best
practices" when the organization started developing the program.

There are advantages and disadvantages to each of these models.

but there must be a workflow where such changes, when already thought through by its native team,

The thinking through, as such, happens during/after construction, not
before construction.

This is why the _only_ way that l10n teams can get a hint of what will
happen, is to have a designated l10n team member, whose sole function is
to sit in on each and every call, and follow both the Bugzilla, and
Commits list, and the use-case and user-story storyboards for each
proposed function, capability, etc.

I realize that that is literally a full time job.

with l10n teams (who are not just localizers, translators, but in most cases promoters of LO in their countries/languages/cultures and can offer a lot of advice what might not be good for their language/cultural environment/law requirements) - before they get introduced. So we need such a forum/discussion point in development process.

+1

I often remember the OOo days where every upcoming bigger feature had a webpage (a kind of a wiki page in the Sun web subworld) made by the developers,

That happened for both minor and major features.
It is a side effect of the waterfall model of software development.

If you roam around on the openoffice.org website, you can still find
some/most of those web pages.

but all this iterative changing (that does lead to better and better results, no doubt about it) in the end hits the l10n teams and makes their members feel like Sisyphus.

Sisyphus was lucky. He knew his fate.

jonathon

This is a fascinating, awareness enriching discussion that will definitely
help the entire documentation team. The resolution of these issues will
make a big impact on the documentation process.

toki kirjoitti 26.04.2018 klo 23:13:

I'm only sad that we are not part of the discussion when we are highly concerned.

That probably has as much to do with where and when the discussions are held, as anything else.

you miss the point. Changing help (documentation project) and UI (UX project) is not a self-enclosed thing.

One of the vices of agile development is that documentation is
considered to be, at best, unnecessary. This applies for both developer
documentation, and user documentation.

Whilst the theory is that Agile Development has the following for End
User Documentation Creation:

* using a topic-oriented approach such as the Darwin Information Typing
Architecture (DITA) or Information MappingTM
* leveraging user stories to produce task-oriented documentation
* applying minimalist principles
* participating as an active team member

the reality is that the usual Agile Development creed on end user
documentation is _They Ain't Gonna Read It So Why Bother Writing It_.

...
> TDF practices agile development, in which nothing is specified until
after delivery.

LibreOffice development does not follow the agile methodology. All this talk about storyboards etc. is completely untrue.

There is an l10n representative present in all Engineering Steering Committee calls. In this case it seems like a minor misunderstanding regarding the videos: https://lists.freedesktop.org/archives/libreoffice/2018-April/080079.html "didn’t realize embedded rather than a link"

Marina's call to stop the legal speculation is highly appreciated (it was really starting to get on my nerves even as a bystander). The legal concerns would in any case target LibreOffice *deployments* and not TDF itself. Naturally TDF and volunteers are willing to cooperate with private and public sector entities having concerns.

If and when videos are included, I assume they are produced from a written script. Providing this script would be the resource any deployments can use to solve their respective translation & a11y conformance issues. Even better would be timed subtitle files (more work).

Ilmari

A next level solution might be to use the cool UI testing framework created by Markus Mohrhard to programmatically define the content of the videos. This would enable anyone to produce versions with different UI languages by simply running the Python UI test and recording the screen. The only thing to solve would be the representation of the mouse pointer.

Ilmari

LibreOffice development does not follow the agile methodology.

Unless you really want a 25,000 word essay on the subject, I'll skip my
essay on Waterfall and relations, including derivatives v Agile and
relations, including derivatives, and how LibO development follows an
agile development process.

concerns would in any case target LibreOffice *deployments* and not TDF

Before being deployed, organizations require the software to meet
certain requirements. In this specific instance, both Section 508, and
ADA. If those checkboxes aren't ticked, LibO won't be considered.

Expecting an organization to fork LibO, simply to ensure compliance with
local law, is way beyond the pale.

jonathon

LibreOffice development does not follow the agile methodology.

Unless you really want a 25,000 word essay on the subject, I'll skip my
essay on Waterfall and relations, including derivatives v Agile and
relations, including derivatives, and how LibO development follows an
agile development process.

No, LibreOffice development is not attached to any management fad. Your essay would merely document coincidentally overlapping characteristics of agile and the actual things going on in LibO development.

concerns would in any case target LibreOffice *deployments* and not TDF

Before being deployed, organizations require the software to meet
certain requirements. In this specific instance, both Section 508, and
ADA. If those checkboxes aren't ticked, LibO won't be considered.

Expecting an organization to fork LibO, simply to ensure compliance with
local law, is way beyond the pale.

Talk of forking is not fitting as there is zero chance documentation contributions of this genre would be refused. What is way beyond the pale is considering LibO to be some dispenser of free beer eternally running on unpaid labour.

Ilmari

+1000

Adolfo,

You can already change the URL of the embedded video in your translation,
so… Moot point?

Change it to what? To a not yet existing Slovenina subtitles version or to
a wiki page saying this is actually not a link to video?
Moot point?

Also, I don’t get your negativity, Martin. You talk about “project leaders”
not communicating when in fact we are all on the same level. If you ever
had a look at the Git log https://cgit.freedesktop.org/
libreoffice/help/log/
you’ll see that we, translators, are the ones pushing fixes to the help
content. So don’t make it seem like there’s some kind of inexistent
hierarchy of people disconnected with the rest of translators. Maybe you’re
the one who should be asking for more information before spreading this
FUD. Olivier has been quite open about adding videos to help, to give a
pointed example.

Sure, I will rest my case and stop spreading FUD, cause that is obviously
what I am doing to this project for the last 20 years ...

Lp, m.