Re: [libreoffice-l10n] Localizing the "Notebookbar"

[Jan Holesovsky]

Hi Martin,

Martin Srebotnjak píše v St 21. 12. 2016 v 22:34 +0100:

> visually that gtknotebook reminds *me* graphically more of a notepad,
> like this
> 
> https://m.riflepaperco.com/media/catalog/product/cache/1/thumbnail/1170x1248/fb193eecb19491ee2d70d1d38e002e96/n/o/notepad-npm011-graph-pad-01.jpg

In the screenshot that was in the reference manual, I guess you are
right; but it depends on the Gtk+ theme that is used - other themes look
different, like eg.:

https://blogs.gnome.org/johannes/files/2009/11/gtknotebook.png

https://valadoc.org/gtk+-3.0/img/example-Gtk.Notebook.png

[but there are many other].

The GtkNotebook is in Gtk+ for years; I think from the very beginning,
my quick search has found some patches going to gtknotebook.c in 1998.

All the best,
Kendy



-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Localizing the "Notebookbar"

[Jan Holesovsky]

Hi Sophie, all,

Sophie píše v St 21. 12. 2016 v 14:25 +0100:

> I really don't know why the UX team had chosen a name that means nothing
> even in English.

A "notebook" is a general name for the tabbed User Interface element, we
took that from Gtk (but it's used elsewhere too), because it is what
the .ui files use:

  https://developer.gnome.org/gtk3/stable/GtkNotebook.html

The name in Gtk was I suppose inspired by a paper notebook like eg. this
one:

  
http://cdn.shopify.com/s/files/1/0264/7911/products/825466934009_1_1024x1024.jpg

The "bar" is hopefully obvious - the same meaning as in menubar or
toolbar.

Hope this background info makes the localization easier :-)

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Default value ("en-US") for the "xml-lang" attribute in XHP files

[Jan Holesovsky]

Hi,

This is one more from the 'cleaning up XHP files' series...

At the moment, the "xml-lang" attribute in the  markup in the
XHP files is mandatory.  But I see no reason for that, it is always just
"en-US", the different locales make sense only for extensions, so I have
created this patch:

  https://gerrit.libreoffice.org/#/c/32296/

This is supposed to ensure that when there is no xml-lang in a given
attribute, it will default to en-US.

It is yet to be tested with the actually removed xml-lang from our help
files via something like:

  git grep -l '\' | xargs sed -i 's/\(]*\) 
xml-lang="en-US"/\1/g'

and updated the DTD to specify xml-lang as optional.

This will not affect the translations in any way.

Comments appreciated :-) - would like to go ahead with this sometime
after the ESC.

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Getting rid of 'l10n' attribute in the help files

[Jan Holesovsky]

Hi,

As discussed in the other mails, 'l10n' is another attribute I'd like to
remove from the help files.

It is unused in the code, and the documentation says: "Contains the
localization status of the old help files and is only used for migration
purposes." - which has happened years and years ago with the helpcontent
-> helpcontent2 migration :-)

This should not affect the l10n process in any way.

OK to go ahead with this bulk change?

It means the following will be run:

  git grep -l '\' | xargs sed -i 's/\(]*\) 
l10n="[^"]*"/\1/g'

and a small follow-up cleanup for the paragraphs that don't have the
attribute on the same line.  Then I'd remove it from the DTD and
xmlhelp/util/compact.xsl too.

I'll wait until after the ESC call this week, for the case there are any
concerns :-)

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Re: [libreoffice-documentation] Re: Getting rid of 'oldref' in the help files

[Jan Holesovsky]

Hi Olivier,

Olivier Hallot píše v So 17. 12. 2016 v 14:54 -0200:

> One thing I'd like to add for evaluation of using XML for the help
> contents in browsers is that,  in my experience:
> 
> *  XSLT (XML style sheets), XPath and XQuery  are another technologies
> to master.
> 
> * An error in a XSLT statement and one get  a blank page or a message
> with very little indications (Firefox)
> 
> * XSLT seems to be an aging technology. Is the industry betting in this
> technology for the future?
> 
> * Rendering XML+XSLT is browser-dependent and is not publicly/widely
> tested by W3C. We may be forced to test the results into a wide set of
> browsers.

Nothing stops us from rewriting the XLST transformation to plain
JavaScript, and handle the XHP files directly via JS if XSLT is blocking
us.  [And this is a reasonably self-contained, and easily testable task:
The XHP -> HTML conversion has to give the same results before and after
the rewrite for all the files.  We've got rid of XSLT in writerfilter
the same way few years ago.]

And maybe we'll eventually end up with using the plain HTML5 directly -
I definitely don't want to block evolution (even though at the moment I
see more drawbacks than gains).

But that's my main point - I want an evolution, not a revolution.  Every
time I hear about "helpcontent*3*" or "let's move to html5", I get
extremely scared, because such claims seem to suggest that we have to
throw away what we have & rewrite everything first, and miss what we
want to achieve in the first place; which from what I know is:

1) add multimedia content

2) make the editing easier

But neither 1) nor 2) have html5 (or a complete rewrite) as a
pre-requisite, for both these goals there is an incremental upgrade path
possible: Improving XHP step by step.

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Re: [libreoffice-documentation] Re: Getting rid of 'oldref' in the help files

[Jan Holesovsky]

Hi,

khagaroth píše v Pá 16. 12. 2016 v 17:51 +0100:

> > I hope you meant HTML 5, because XHTML is a dead end (and good riddance).
> 
> html does not have markup for some of the semantics that we have (and need)
> > in the help files (like  or  to name few)
> >
> 
> Both  and  are part of HTML 5 and there is a good chance
> the other things are as well.

They are, but they mean a completely different thing than what they mean
in XHP ;-)

 in XHP is more like .

Similarly  is more like a  with some associated css.

Again - I'm talking semantics;  is a general thing, and has no
semantics by itself, similarly .  We'd lose this by converting to a
plain HTML.

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Re: Getting rid of 'oldref' in the help files

[Jan Holesovsky]

Hi Jan,

Jan Iversen píše v Pá 16. 12. 2016 v 16:27 +0100:

> > this change is supposed to be transparent for L10n and
> > Documentation teams, but they should know :-)
> 
> It does not seem transparent for the few languages that do not use pootle (sl 
> and sr) please do not forget those.

Thanks for the reminder.  I hope Cloph can do the upgrade for them some
way that fits them too, though?

> It does also influence the help repo (of course), since the change will be a 
> very big commit.
> 
> > [Or - any objections to this change?]
> 
> No objections as I think it is a good and welcome change, just a question.
> 
> As we discussed in ESC (and Oliver sort of pushed) it seems the goal
> is to move away from .xhp to .xhtml (if I understood it correct). If
> decided do we then want to do that as a set of small steps or make 1
> script that does it ?

I tried to explain on the documentation@ why a big-bang move to html is
not a good idea from many reasons in another thread; to name the most
important ones:

* big-bang "let's abandon one technology and hooray for another one"
  always brings lots of regressions that are hard to fix in a timely
  manner; incremental changes are easier to maintain

* html does not have markup for some of the semantics that we have (and
  need) in the help files (like  or  to name few)

* there are many ways how to describe the same thing in html ('s and
  's vs.  and  vs. 's with css vs. who-knows-what)
  which would make the help harder to maintain, if we eg. want to reuse
  the information from there to generate other representations (like
  eg. books or so)

> Please just see this as a question of how often to we want to run these 
> conversions.

One more may be needed if we agree that the id="..." attribute could be
done non-mandatory, because that one affects the msgctx too.

If we want to make the XHP markup look more like HTML markup (which I
don't object in general & this is up to agreement between between the
Documentation and L10n people), there might be additional conversions
needed, for things like  ->  etc. - but I'd like to keep
this separate from the cleanup effort / topic.

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Getting rid of 'oldref' in the help files

[Jan Holesovsky]

Hi Cloph, all,

I've recently proposed some help cleanups on the documentation@ ML, and
this is the first one of them.  I'm cross-posting to l10n@ and
documentation@ - this change is supposed to be transparent for L10n and
Documentation teams, but they should know :-)

The idea is to get rid of the 'oldref' attribute in the help files; ie.
change

  Heading

to

  Heading

The 'oldref' comes from helpcontent -> helpcontent2 migration, and the
documentation says "This contains the reference number used by the old
help files and is only used for migration purposes."

Unfortunately, it is used in the msgctx flag in the .po files, like:

#: main0503.xhp
msgctxt ""
"main0503.xhp\n"
"hd_id3155084\n"
"21\n"
"help.text"
msgid "Flexible Application Interface"
msgstr "Snadno přizpůsobitelné uživatelské rozhraní"

The "21\n" above is the oldref.

As we talked on the IRC - unless there are any objections, can you
please do your magic with the next translation update so that we remove
these oldrefs from the helpcontent, the .po templates, and .po
translations themselves?

The helpcontent2 part of that is this:

  git grep -l 'oldref="[0-9]*"' | xargs sed -i 's/ 

[libreoffice-l10n] Re: [libreoffice-documentation] Help-files: Large-scale 'cosmetic' changes

[Jan Holesovsky]

Hi Tom,

Tom Davies píše v St 16. 12. 2015 v 19:15 +:

> It is about the Help Files.  The Documentation Team may be able to
> make some much-needed changes to the help-files.  However, it is to
> solve a problem that only exists in English.  For all other languages
> it is, beyond doubt, already corrected purely through the translation
> process.
> 
> Is there a system or tool that allows such sweeping changes without
> marking completed translations as incomplete?
> 
> I think there was some discussion about developing such a tool but i
> imagine it would be extremely difficult to make something like that.
> So i would be surprised if there is anything yet.

I don't think it is terribly difficult to create such a tool, the
problem is running it - it has to by done by an admin with the access to
Pootle, so doing it string by string for each such much needed (but for
other languages cosmetic) change would be rather sub-optimal.

But - what about to introduce an 'en_US' translation in the Pootle,
where native speakers could improve the wording without changing the
meaning?  Then once per the release cycle, these could be copied back in
a way that it marks no translations fuzzy.

[Again - this does not cover those who download the .po files from
Pootle, and then upload back; but hopefully with a proper communication,
giving them enough time to upload their work before such a change, this
could be less of a problem too?]

Does that work?

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Possible help files rename?

[Jan Holesovsky]

Hi Martin,

Martin Srebotnjak píše v Út 24. 11. 2015 v 21:57 +0100:

> I am not sure we are talking about the same thing or that I understand
> this correctly.
> 
> They change the names of the help files (i.e. calc/01.po is now
> calcsfirsthelpfilewithhelpaboutfunctions.po). For the migration
> process they become new po files.

Nope, did not intend to change the directories, so I was happy to hear
that the .po files are named by the directories.

So as a result, calc/01.po will still stay calc/01.po; only the
filenames inside would change - eg. in:

#. ZxQeC
#: main.xhp
msgctxt ""
"main.xhp\n"
"tit\n"
"help.text"
msgid "Welcome to the $[officename] Calc Help"
msgstr "Vítejte v nápovědě k $[officename] Calc"

only the 'main.xhp' would change to 
'-Welcome-to-the-officename-Calc-Help.xhp' resulting in

#. ZxQeC
#: -Welcome-to-the-officename-Calc-Help.xhp
msgctxt ""
"-Welcome-to-the-officename-Calc-Help.xhp\n"
"tit\n"
"help.text"
msgid "Welcome to the $[officename] Calc Help"
msgstr "Vítejte v nápovědě k $[officename] Calc"

Sorry for not being precise in my question previously, but first I
needed to understand how exactly the .xhp's map to the .po files :-)

Does this work / is this change possible without much hassle?

Thank you again,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-documentation] Re: [libreoffice-l10n] Possible help files rename?

[Jan Holesovsky]

Hi Sophie,

Sophie píše v St 25. 11. 2015 v 11:52 +0100:

> Why do we want to change if the main_transform.xsl file is working now
> correctly and allow an easy search? I agree that the file name remains
> not easy to understand, but if a tool solve that, where is the issue
> then?

From my point of view, it is always good to fix root cause, then to try
to pile workaround on top of each other to achieve something that would
be possible by fixing the initial problem in the first place.

Additional file means additional complexity, and additional thing to
explain to the newcomers - so that's why I am interested in fixing this
by the rename.

But again - for the moment I'm only researching what are the
consequences & if this is acceptable by the l10n community :-)

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Possible help files rename?

[Jan Holesovsky]

Hi Martin,

Martin Srebotnjak píše v Út 24. 11. 2015 v 15:54 +0100:

> Please, once more, do not do any "l'art pour l'art"-istic changes that
> might cause any kind of trouble to localizers.
> 
> There are many more things to invest time and will in first - to write
> missing help content, to edit the help content, to make
> wiki-served-help fully localizable, to have manuals (getting started
> guides) up-to-date etc.

Exactly!  And to be able to do so, we need to lower the entry barrier,
so that more people can write the help content, update the manuals, etc.

We have just seen a guy interested in editing help, and this was one of
his struggles there - that he just couldn't find the help file he needs
to edit.  Asking him to grep all the main0123.xhp files (and alike) is
just as nice as telling him "go away, we don't want you" :-(

That's why I am interested to learn what are the technical & workflow
difficulties to make the barrier lower, and what is the impact on the
localizers.

We need to do changes to be more open for documentation contributions,
that's something we just cannot avoid, otherwise our help will be
completely outdated soon.  So I'm asking if (and what) we can do in a
way that causes no or only minimal trouble.

> Most localizers localize from Pootle and I am sure that po files there
> could be given additional description what part of UI or help they
> cover, if really someone feels lost.

"Most localizers localize from Pootle" together with:

> 2015-11-24 13:22 GMT+01:00 Andras Timar :

> > It is
> > possible to automatically replace file names in git and in Pootle, but
> > this can cause disruption for translators who work offline, and
> > translation memories have to be regenerated.

actually makes me think that only a small fraction of translators would
be actually disrupted, because for those using Pootle, it would be
transparent.  So did I misunderstand?

Thank you for your help!

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Possible help files rename?

[Jan Holesovsky]

Hi Regina, all,

Regina Henschel píše v St 18. 11. 2015 v 21:32 +0100:

> most of the file names are build of numbers and it 
> is hard to identify the relevant file.

That's indeed true :-)

I wonder - would a large scale rename to something more readable (like
eg. filename constructed from the  tag) be more appreciated by
people editing help?

L10n people - any blockers from the tooling point of view that hinder
that, please?  Would it mean that the .po files have to be renamed too,
and if yes, it is possible to do that somehow automatically?

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Re: [libreoffice-documentation] Are id attributes needed on paragraphs and headings in .xhp help files?

[Jan Holesovsky]

Hi Regina,

Regina Henschel píše v St 07. 10. 2015 v 15:33 +0200:

> the doctype definition xmlhelp.dtd makes the id attribute of type 
> REQUIRED in all cases. It is needed surely for sections and variables, 
> because they are embedded elsewhere and need to be referenced.
> 
> But is the id attribute needed for headings and paragraphs too? There 
> exists already some files having paragraphs without an id attribute, and 
> the files in the delivered .jar archives have stripped the attribute 
> too. But I do not know whether processes exists, that need it. What 
> about translation, or transformation to the Wikihelp, or the help 
> compiler itself, or while generating the .jar files?
> 
> If the id attribute is not needed, then the authoring tools can do 
> without generating id values.

Sorry for the late answer.  From what I know, the paragraph ID's are not
necessary for wikihelp, and I doubt they are necessary for the help
compiler.

Let me add the l10n team to see if they are necessary for the
translations...  Are they?

If not - then I'd remove them from the tooling, dtd, and from the help
repository too, to reduce the noise there :-)

Thank you,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Backport to 5.0 / string change

[Jan Holesovsky]

Hi all,

Naruhiko Ogasawara píše v Pá 14. 08. 2015 v 15:04 +:

 
 Is that OK from the l10n point of view, please?
 
 One more OK from Japanese Team :).

Thanks so much for all the OK's, pushed it now :-)

All the best,
Kendy



-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Backport to 5.0 / string change

[Jan Holesovsky]

Hi,

I have a fix for 

https://bugs.documentfoundation.org/show_bug.cgi?id=80866

that consists of two parts - a revert, and a string change:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac2f6018e01cbd24f394911e8bcd3ee3c217eb51

The revert is now under review for inclusion to 5.0, and Adolfo suggests
to get the string change there too:

https://gerrit.libreoffice.org/#/c/17681/

Is that OK from the l10n point of view, please?

Thank you,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Backport to 5.0 / string change

[Jan Holesovsky]

Hi Martin,

Martin Srebotnjak píše v Čt 13. 08. 2015 v 16:05 +0200:

 What version is this planned for? 5.0.1 or 5.0.2?

5.0.2.

All the best,
Kendy



-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams

[Jan Holesovsky]

Hi Jesper,

Jesper Hertel píše v Út 27. 01. 2015 v 14:08 +0100:

 
  That's why we were thinking of a en_US version as a real
 language and
  different from the sources and
 
 But at some stage this will have to apply to the sources
 
 Why?

Because the sources are the ultimate version of the strings.  Who would
be deciding if a change should be applied in the sources (ie. it is a
change needed for all languages) and what is just making the original
more consistent?  And again - what to do if the person mis-judges?

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Re: Workflow between dev, UX and l10n teams

[Jan Holesovsky]

Hi Sophie, Mihovil,

Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100:

 Cosmetic changes (~ to _ or Status to Status: or ... to … or those 
 different quote styles I don't even have on my keyboard) and anything 
 similliar - NOT OK if you don't script it for all languages
 Cosmetic changes (Big brown fox - Big Brown Fox) - NOT OK at all, 
 change just for en_us, don't change my strings and don't even notify me 
 you did it in en_us

I see 2 problems here:

1) There is no tool that would detect these trivial changes, and would
   act accordingly.

2) The texts for translations are updated in big 'code' drops, without
   possibility for translators to affect the process in any way - for
   them it is too late.

Regarding 1) - I thought that Pootle is detecting the trivial changes
some way, and offering the original translation.  Is it not?  What can
be done to improve that, so that for translators it is just a matter of
checking; not a matter of translating?  [Or even what you suggest - that
it would just update the source strings without touching the
translations?]

Regarding 2) - I'm glad that you say that the strings will be now
getting to Pootle immediately after the code / string changes in master.
I think it is important that the translators will be able to deal with
the changes immediately, not several months later, so that they can
cooperate, and not only react.

In general, I don't think that setting extremely strict rules works,
unless you have means how to enforce them - like via a commit hook or so
(and it is extremely unpopular way to do things).

It is always much better to communicate - if you see a developer who
commits a change that causes you grief, please _do_ tell _him/her_
immediately, and - if possible - in a friendly way.  I'm sure he/she
will do much better the next time.

Unfortunately I did not see any signs of notice that this or that change
was problematic for localization on the development mailing list - were
there such warnings there?  Like commit XY caused AB - please don't do
such things, unless we agree how to do that effectively / without pain?
Or was it impossible so far because the strings in Pootle were not
synced with master?

Also - should we have a 'Localization' recurring topic in the ESC?  Who
would be the right representative there, please?

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Amending and enhancing the help files

[Jan Holesovsky]

Hi Markus,

Markus Mohrhard píše v St 02. 07. 2014 v 18:51 +0200:

 
 I believe 1) is the easiest from the development point of
 view, and I
 think also most consistent for translation - as you won't have
 to sync
 between 2 tools to get the help completely translated.  But
 now I am not
 completely sure how that fits the Markus' current tooling that
 he has
 already prototyped - Markus, can we translate even the
 extended tooltips
 in the Translate extension?  Does that fit you?

 
 I have no idea if that is possible. The biggest problem would be the
 ones that are not part of the visible help texts.

Ah yes; so I thought there would be a special page that would only hold
those invisible ones.

I mean, if we had them all using a template like

{{Tooltip|modules/swriter/ui/flddocinfopage/fixed|Inserts the field as static 
content, that is, the field cannot be updated.}}

it could be used inline for the visible ones, or in a special page that
wouldn't be part of the help itself for the invisible ones.  But no idea
if the Translate extension can extract only the parameter of the
template in some way if we mark it so, or if the entire above template
definition would appear for translation.

Having said that - seeing what actually is being used as the extended
tooltips, I am not sure if it is a huge loss if we go the 3) way, as
Markus points out:

 Currently I personally would tend to the third solution but I
 understand the concerns of the translators. My idea was that as we
 keep the already translated strings this is not too bad.

All the best,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Re: LibreOffice Help

[Jan Holesovsky]

Hi Martin,

Martin Srebotnjak píše v Út 08. 10. 2013 v 22:24 +0200:

 maintaining and translating LO help via wiki is a no-go for localization
 (teams).

No need for any strong words here I hope - as you have seen in the past,
we have always agreed wrt. wikihelp on something that worked for all :-)
Please read further, hopefully you'll reconsider your hard 'no-go' a
bit.

At the moment, 2 efforts are ongoing:

1) Kill the internal help system, and use html instead

In order to be able to do that, we need to implement the search and
indexing functionality in Javascript, and that is what Rob is working
on.  For you, as the translators, nothing changes, this is orthogonal to
your work - it will be just taken from git  pootle (or potentially
wikihelp or whatever source), converted to html, and the result will be
used in the LibreOffice build.

The reasoning for this is that a) everyone has a browser these days, b)
we won't have to maintain the code for the internal help system at all,
and c) we know it is doable - there are some proprietary solutions out
there that do exactly this.

This does not touch your workflow at all.

2) Make wikihelp the source of the help

This is something we need to do in order to be able to improve our help.
Virtually nobody writes help these days, because of the format that is
used there, and the workflow that need committing to git etc.  Only
fraction of the new features has suitable help, and we need to change
this.

But - and that is important - we of course need to do it in a way that
fits everyone, l10n most of all :-)  So as I assured you many times, no
translation will be lost.  We only have to agree what fits you best; and
before you answer that you want nothing else than Pootle, it would be
good to test what Markus is about to set up; I am sure he'll write you
more about that when it is ready for testing - and it will be up to you
to decide if it is acceptable for you, or tell him what features are
missing.  You will _not_ have to translate entire pages, the system is
going to be very similar to Pootle, based on
http://www.mediawiki.org/wiki/Extension:Translate .

I know of the following advantages that would improve over our current
workflow:

- No more mistakes in the xml markup [happens with the current system
  from time to time that a mistake in the translation kills the help
  page]

- Possibility to preview the translated sentence in context of the
  entire paragraph or page _immediately_, without you having to wait for
  a developer build [impossible with current system].  This would make
  you independent on developers, and would give you more time to
  translate.

- Possibility to translate via .po files [as I know, the solution that
  Markus has in mind allows you to export to .po, and import back]

If you are afraid of the editable wikihelp in general, please don't be -
only l10n and documentation people will have access, and I am sure
you'll be able to agree what kind of changes are acceptable, and what
are not, in order not to introduce problems for you.

So please - open your mind here, and test it when it is prepared for
testing, your feedback will be extremely valuable.

Thank you,
Kendy


-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Translations of the help.libreoffice.org main page

[Jan Holesovsky]

Hi,

I got a report that

https://help.libreoffice.org/Main_Page

is not translated - which is true.  In order to be translated to your
language (one of CA, CS, DA, DE, ES, FR, HU, IT, JA, KO, NL, PL, PT,
PT-BR, RU, SL, SV, VI, ZH-CN, ZH-TW), I'd like to ask you for the
translation of its source, that is of

https://help.libreoffice.org/WikiAction/edit/Main_Page

If you can do it, please send it to me as a reply to this mail - I do
not want to do Wikihelp editable, as all the pages except the Main_Page
are still just generated from the LibreOffice Help, and it might lead to
confusion.

Thank you a lot,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Translations of the help.libreoffice.org main page

[Jan Holesovsky]

Hi Martin,

Martin Srebotnjak píše v Út 15. 01. 2013 v 21:00 +0100:

 Jan, I will send the translation.

Thank you! :-)

 But I strongly oppose that anyone will be able to edit help pages via
 wiki, this was you idea years ago and most translation communities
 oppose it and please stop writing that!

The deal that anything that would make the wikihelp editable will affect
translators in no negative way is still in place of course - don't
worry.  Even if we manage to do the Wikihelp editable one day, it will
be only the English source, and the rest will go through Pootle, with
everything converted etc.

Please consider the documentation writers too - the current way of
writing Help is unbearable for everybody who attempts that.

Either way, the only (very slowly) ongoing work now is to split the
Extended Tooltips (the ahelp pieces in the Help) from the Help itself
for performance reasons [but it would help the above too], so nothing to
really panic about.

I hope this clears your concerns.

All the best,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Translations of the help.libreoffice.org main page

[Jan Holesovsky]

Hi Martin,

I am not sure what has upset you that much - are you going to FOSDEM by
chance?  Would be great to talk face to face.  Please read more inline:

Martin Srebotnjak píše v Út 15. 01. 2013 v 22:55 +0100:

 no, your writing does not console me, I am afraid of solo actions of
 documentation writers that might make changes that are not in favor of
 the product (although some writer is personally enthusiastic about
 them, just like you are about making English help editable in wiki).
 
 If you imagine - copy pasting or moving some page here and there in
 the wiki structure or changing wording here and there is an easy job
 in the wiki, but for translators this could mean many empty strings in
 Pootle of something that has been already almost fully translated. We
 will be working like mad because of such small changes. Translated
 help will never be 100% localized. LibreOffice will not be up to the
 norms for adoption of software in government and civic institutions.

In case we change the help to wiki as the source [NOTE: if at all; at
some stage; nobody is working on this if I'm not mistaken], there is of
course a trivial solution for this - work closely with the
documentation/help authors; forget about 'we' and 'they' and the 1st
time somebody does something bad just work with him/her to revert/fix
that.

Of course, some additional technical solutions, like detection of moves,
fuzzy translations, re-generating translations nightly to check for
changes that are too aggressive  revert in the wiki, etc. etc. might
help too - there is no need to fear of changes in advance.

And - even as a wiki, the help can have a release cycle as the current
help has, aligned with the product release, in order to be able to
achieve 100% translation.

 So I think it is great that it is currently hard to change help - a
 technical writer must really be precise in the change she wants - and
 this leads also to a very localized change also for localizers.
 Also, help system is not so bad that it would need a total revamp. And
 being translated in so many languages it would generate 100x the work
 of a single writer's change.

No, there is nothing great about being hard to change help.  Our help
sucks in the current form, and I am talking content - there is so many
useless pages there that we have to translate to our languages (yes, I
am translating too).

And of course, if anybody wanted, it is much easier to create nightmares
with the current help source than it would potentially be with wiki as
the source.

 So I will remain upset even though I do not want to.

I don't understand why.

 Changing the
 concept of help is not just a question of help writers/editors and
 Kendy, who developed the po-wiki translation system, but it is a
 joint question to be discussed and decided with the l10n community.

Sure, completely agree with this.  I just have to add that blocking
changes without understanding is as unacceptable as changing something
without discussions.

 But it seems you do not want to talk about it with the l10n people.

I do not understand why do you have this feeling; of course I do want to
talk to you - but it is hard when you start shouting whenever I only
mention wikihelp ;-)

BTW, with 2423 translations, I hope could be considered a l10n guy
myself these days, couldn't I?

 Shouldn't such a change be discussed in the boards of TDF as it
 affects so many language teams?

Technical Steering Committee is more proper I guess; but before that I
think it will be best if we two understand each other as the first
thing.

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] REMINDER: Release 3.6.0-rc2 from libreoffice-3-6 branch

[Jan Holesovsky]

Hi,

On 2012-07-17 at 16:54 +0200, khagaroth wrote:

 Then perhaps the toplevel tree entries shouldn't be selectable anymore
 and clicking on them should move the selection to (and display) the
 first corresponding subitem.

I thought there was even an EasyHack for this somewhere, but now I
cannot find it - does anybody recall if it was there?

All the best,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Re: [Libreoffice-qa] Online update service up running

[Jan Holesovsky]

Hi Korrawit, all,

On 2012-01-03 at 11:09 +0700, Korrawit Pruegsanusak wrote:

  Clicking on help (with installed help pack) doesn't give any information.
 
 Well, we should *partially* revert
 https://bugs.freedesktop.org/show_bug.cgi?id=33468
 Links to commit are in comment 3 and 4.

Ah - thanks! :-)

 But IMHO we are string-freezed, so this will happen in master (3.6) only, 
 right?

L10n people - please, is it OK for you to bring back the Online update
help this late even for 3.5?  Hopefully the text might still be ~easily
restorable from the older translations?

Thank you,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Re: [Libreoffice-qa] Online update service up running

[Jan Holesovsky]

Hi,
On 2012-01-03 at 09:51 +0100, Martin Srebotnjak wrote:

  L10n people - please, is it OK for you to bring back the Online update
  help this late even for 3.5?  Hopefully the text might still be ~easily
  restorable from the older translations?
 
 AFAIAC, if it is only a restore with minor updates, then it should not be a
 problem. It would be much worse to see only English text there, even if
 applicable translations already exist somewhere ...

So - good news :-)  The text was never removed, only its building, so it
should not affect the translations in any way.  Now it is building
again, so the update-related dialogs should have help again.

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Online update service + localized download URLs

[Jan Holesovsky]

Hi,

The service that warns you that there is a newer LibreOffice version out
is up  running, and when you have Beta1, it should inform you about the
availability of Beta2, and offer you to redirect to its download page.

Our QA guys noticed that the URLs it offers are not localized; ie. you
are always pointed to the International download URLs, while in many
cases there are nice translated pages.  Here I need your help :-)
Please - can you fill in the following form for your language, and send
back to me?

Language: [lang code, like 'en', 'fr', 'de', ...]
Download page: [equivalent of http://www.libreoffice.org/download/]
Pre-release download page: [equivalent of 
http://www.libreoffice.org/download/pre-releases/]

[example for German language:

Language: de
Download page: http://de.libreoffice.org/download/
Pre-release download page: http://de.libreoffice.org/download/testversionen/
]

Thank you for your help!

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-l10n] Re: Kendy's Work in LO GUI+Help

[Jan Holesovsky]

Hi Martin,

On 2011-03-31 at 12:22 +0200, Martin Srebotnjak wrote:

 I was flabbergasted by the forced-unto-us not-so-functional online
 help system, as you might have read several times on this list.

I am sorry that you feel personally offended by that; the online help is
not perfect - but for those who feel that as a stopper, there is always
the possibility to install the offline version.

And patches are greatly appreciated!  I have no intention to let it be
bad; it is an easy code, some 1300 lines of Python:

http://cgit.freedesktop.org/libreoffice/help/tree/helpcontent2/to-wiki/wikiconv2.py

 This is something that mostly targets the non-English speaking
 communities (at least on Linux and OS X) - and we were not asked how
 the end product should look like. Since it was implemented there were
 no major enhancements and the non-functionality of that online help is
 still obvious to all.

http://wiki.documentfoundation.org/Development/Wikihelp was created
after I did the wrong step that I developed the initial version without
consulting you.  I thought that this version was agreed on the l10n
mailing list - was it not?

 Now the thing will go further:
 http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-03.html#2011-03-31T11_35_21.htm
 What are the OFFICIAL specs, confirmed by the LibreOffice community
 for further development of the online help?

I am extremely sorry if I misunderstood that the above mentioned spec
was generally embraced; but let me assure you once again that I won't do
any more work for you.  You may have noticed that I become a translator
in the meantime too (http://translations.documentfoundation.org/cs/), so
now I have much better understanding when you talk about the translator
needs.

  What is our approach, who is us?

In this context, it was those who contributed to the development of the
conversion tool.

  Does it include us, the L10N community, translating and updating the
 help, or who? Did the L10N teams leads give their perspective on this
 issue?

It is in line with the spec, so in fact yes, I thought that it was
discussed, and agreed.

 The online help system developer has also revamped the search toolbar
 to behave more like in [...] Firefox:
 http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-03.html#2011-03-29T09_43_06.htm
 and he is now also mentoring students cleaning the UI. While some
 tasks in
 http://wiki.documentfoundation.org/Development/Gsoc/Ideas#UI_cleanup
 look like real cleanup, some might really be re-designs.
 
 I am wondering if LO is (unlike OOo) going in the direction that every
 developer can change the UI without consent from the community. (That
 could lead to LO developers thinking loud on their blogs like this:
 Playing with the LO code yesterday I decided that LO will now drop
 the Base component, because I don't like it, it just takes place on
 disk, it should be an extension.) Or maybe there are some individuals
 (or employees of some companies) with greater rights and privileges
 than others in the LO community?

Well - should we vote on each and every feature that would go into
LibreOffice?  That would bore people to death after a while ;-)  If you
look at the development mailing list, each and every patch that does
more good than bad is committed; and everything can be again reverted,
or subsequently fixed, no problem there.

 Should not the UI changes be discussed in length? With some usability
 studies etc.?

If there is somebody who comes up with a beautiful design and convinces
enough people to implement it, that's perfect!  But do you remember the
amount of controversy that Renaissance project brought?  And where did
it end up?  Lots of discussions, and no result.

So my conclusion is never let perfect be enemy of the good ;-)  There
are so many obviously incorrect things in the UI, that you just cannot
make things worse when you fix that.  And if you do, there is a plenty
of other developers who will just fix your error.  Or users make me
revert that.  Whatever :-) - that's the beauty of freedom.

  Will the disappointment with the decision-making process lead to
 further forks of LibreOffice or to the return of translation teams
 back to the OOo project?

Again - I promise to do everything to save you work.  When the help
switches to something that would need change of your workflow, the l10n
people will be the first to be involved.

But the GSoC task does not involve any change for you, it is only about
the technical part, and that is converting the wikihelp to native help
systems.

 I am writing here, because I think this is not a single-developer
 decision nor just a GUI/developer-people-thing, and because I would
 like to know the official specs for the Help and GUI redesign/cleanup
 as well as the opinion of the L10N teams, because international help
 system is very much in the hands of the L10N teams.
 
 I do like Kendy and his commitment to this project, I do know that he
 means well and is 

Re: [libreoffice-l10n] replace Slovak help by Czech translation

[Jan Holesovsky]

Hi Milos,

On 2011-03-16 at 17:33 +0100, Milos Sramek wrote:

 Would it be possible to use (temporarily) the Czech translation (but
 only of the help, please), which is complete? Slovak and Czech languages
 are very similar and we have no problem with reading Czech texts.

We can do that easily for the online help, Slovak is not there at all,
so the redirect to Czech first would not be that annoying I think.

 Once the Slovak one will be usable, I will be happy to ask for the
 change. In Debian they do that this way, but in other Linux
 distributions and in Windows it is the semitransleted Slovak version,
 which is being installed.

In Debian, you mean the LibreOffice translations in Debian?  Then I
think we should use their patch generally ;-)

BTW - are you the hero behind the 96% Slovak translation in Pootle?
Great stuff, and thank you very much for that - I am using it as an
inspiration for my Czech translations :-)

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/l10n/
*** All posts to this list are publicly archived for eternity ***

[libreoffice-l10n] Branch libreoffice-3-3-1 created

[Jan Holesovsky]

Hi all,

Similarly to the release of 3.3.0, we have created a branch for the
stabilization of the 3.3.1, called 'libreoffice-3-3-1'.  It is not based
on a tag yet, Petr will tag tomorrow.

The following rules apply:

+ any commit has to be reviewed by 3 people
+ preferably commit only translation fixes, or blocker fixes
+ only cherry-pick from the libreoffice-3-3 branch

The 'libreoffice-3-3' branch is still active, will be used for the next
bugfix release (3.3.2), and has the following rules:

+ any commit needs review by 1 person
+ only safe fixes are allowed
+ changes are regularly merged into master

The 'master' branch is used for 3.4 development and has the rules:

+ free commit; do your best to do not break build and
  functionality
+ any development allowed

For further information about the roadmap, please check

http://wiki.documentfoundation.org/ReleasePlan

Now, if you want to switch your clone to the libreoffice-3-3-1 branch,
do:

git pull -r
bin/g pull -r
git checkout -b libreoffice-3-3-1 origin/libreoffice-3-3-1
bin/g checkout -b libreoffice-3-3-1 origin/libreoffice-3-3-1

Hopefully it will work for you :-)  Most probably, you will also want to
do (if you haven't done it yet):

git config --global push.default tracking

When you do git push with this, git will push only the branch you are
on; ie. libreoffice-3-3-1 when you have switched to it.  This will
save you some git shouting at you.

Happy hacking,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/l10n/
*** All posts to this list are publicly archived for eternity ***

[libreoffice-l10n] Re: [Libreoffice] Wikihelp: Uploaded translations

[Jan Holesovsky]

Hi,

On 2011-01-21 at 18:33 +0100, Jan Holesovsky wrote:

 I have uploaded the wikihelp translations to
 http://help.libreoffice.org ,  so far for the following languages:
[...]
 The logic to show the page in the right language immediately after you
 issue help is not implemented yet, I hope to get it done on Monday.

Done now, please test.  I did not upload any additional languages yet,
unfortunately, so you have to be use one of the languages mentioned in
the previous mail.

Enjoy,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/l10n/
*** All posts to this list are publicly archived for eternity ***

[libreoffice-l10n] Wikihelp: Uploaded translations

[Jan Holesovsky]

Hi all,

Yesterday I have uploaded the wikihelp translations to
http://help.libreoffice.org ,  so far for the following languages:

en, ca, cs, de, es, fr, hu, it, ja, pt, pt-BR, ru, sl, vi

Please let me know if your language's help is translated, and you want
to see it in wikihelp :-)

From now on, the pages have the language choice at the top; if not, it
is necessary to clear the wiki's cache using action=purge for that page,
like:

http://help.libreoffice.org/index.php5?title=Chart/Charts_inaction=purge

[where Charts/Charts_in is the name of the page where you don't see the
language choice].

Unfortunately, I did not find a way to clear the cache for the entire
wiki at one go, sorry for that.  If anybody of you knows, ideas
appreciated :-)

The logic to show the page in the right language immediately after you
issue help is not implemented yet, I hope to get it done on Monday.

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/l10n/
*** All posts to this list are publicly archived for eternity ***

Re: [libreoffice-l10n] Czech translations in Pootle

[Jan Holesovsky]

Hi Rimas,

On 2011-01-03 at 15:39 +0200, Rimas Kudelis wrote:

  I just checked the Czech translations in the LO Pootle - there is a
  Czech project there, even some translations, but nobody listed under
  http://wiki.documentfoundation.org/Language_Teams as responsible for
  Czech :-)
 
 I guess we don't have a Czech team yet. The stings that you see 
 translated are a legacy from 2008. Here's an excerpt from the .po file 
 header:
 
 PO-Revision-Date: 2008-09-18 15:10+0100\n
 Last-Translator: Kamikami...@gmail.com\n

OK, I see :-)

  I spotted few typos I'd like to fix - any chance to get the appropriate
  permissions, please?  My login name is 'kendy' on Pootle.
 
 You now have the admin permissions on Czech. Feel free to list yourself 
 on the wiki too, especially if you are willing to do more than just fix 
 a few typos. ;)

Great, thank you a lot!  Indeed - I am interested in more, see my other
mails about getting rid of the sdf files; and of course the best for me
to check what is possible is easiest through translating few pieces here
and there into my native lang :-)

Thank you,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/l10n/
*** All posts to this list are publicly archived for eternity ***

Re: [Libreoffice] [libreoffice-l10n] LO Pootle

[Jan Holesovsky]

Hi Andras,

On 2010-12-30 at 09:13 +0100, Andras Timar wrote:

  BTW - would it help you if we got rid of the sdf files, and instead we
  had .po files in the l10n git repository?  [For sure it would help us
  who work with the git repos, because the sdf file format is just
  something incredibly terrible for version control.]  Would you be able
  to merge directly from the OOo Pootle, or from .po files produced by
  that, or do you still need .sdf for part of your workflow?
 
 Assumption: translate-toolkit can convert translatable content back and
 forth without loss of information.

Yes, I assume the same thing :-)

 I believe this assumption is true. Translate-toolkit has been used for a
 long time by many teams. My suggestion is that all l10n teams should use
 Pootle to submit their translations. This does not mean that they must
 use Pootle to translate. They can use Pootle, offline PO editing tools,
 xliff, or edit sdf file directly - it does not matter. However at the
 end translations must be uploaded to Pootle in .po format. Pootle - with
 a git back-end - will contain the master copy of translations.

Sounds great to me.

 English sdf file should be produced regularly for Pootle update. l10n
 repository will be obsolete. Build should take .po files from git
 (Pootle back-end) and generate localized sdf files build-time.
 
 Problems:
 
 1. How to import existing LibreOffice translations to Pootle?
 
 l10n repository contains monolingual (and sometimes outdated) sdf files.
 We can export up-to-date bilingual (en-US + translated) sdf files from
 the source, but we cannot make a difference between untranslated strings
 and strings that are intentionally same as en-US (URLs, code, function
 names, language names etc.). Sun stored translations in a database (not
 public) and they kept track of this information - this cannot be
 extracted from the source.

I think that with a simple heuristic, we might get quite good results:

- if there exists a language that has a translation = mark the string
as not translated
- if there no translation in any language, mark as fuzzy; it probably is
an URL or something

We can play a bit with the % of languages that have the translation for
the fuzzy / not translated at all split; I hope it might work reasonably
well.

 2. How to merge translations from OpenOffice.org?
 
 I think it should be decided individually for each language team.
 Automatic merge should happen for only those languages that do not have
 LibreOffice translators. Of course technical support should be provided
 for all. Translators don't need to understand the technical details. I
 think members of this list have the knowledge, we can put together a
 good process.

Sounds good to me.

Thank you,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/l10n/
*** All posts to this list are publicly archived for eternity ***

Re: [Libreoffice] [libreoffice-l10n] Re: Update of the localization files

[Jan Holesovsky]

Hi Sophie,

On 2010-12-29 at 19:52 +0300, Sophie Gautier wrote:

 But we need to merge the strings quiet soon now because we didn't have 
 the opportunity any more to fix l10n issues in OOo 3.3 since

I am confused - did you mean 3.4 here, or I did not understand your
initial mail, please?

Thank you,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/l10n/
*** All posts to this list are publicly archived for eternity ***

[libreoffice-l10n] LO Pootle

[Jan Holesovsky]

Hi Sophie,

Thank you for all the explanations! :-)

On 2010-12-29 at 21:00 +0300, Sophie Gautier wrote:

 This is now two/three months that we didn't touch the files because we 
 do not have them in the LO Pootle repository and we are not working any 
 more on the OOo Pootle repository. So some teams have now a fair amount 
 of issues to fix in their files, that will take time and resources, and 
 we need to have the complete set of files in the LO Pootle repository 
 for that.

I see, OK.  What is at the moment blocking the import of the content of
the OOo Pootle into the LO Pootle, please?  Just some missing tooling,
or the decision of what is the source for the translations  how to
organize them?

On 2010-12-29 at 21:00 +0300, Sophie Gautier wrote:

  Ah, maybe I understand now ;-)  So of course, it is up to you to define
  if you want to have the translations merged from the OOo tree to the LO
  tree for 3.4, or not.  I understand it that you'd prefer not to, ie.
  l10n repo (containing the localize.sdf's) untouched by the merges from
  OOo, right?
 
 That was what I was not sure about: all the new features and bug fixes 
 for OOo will be merged to the LO tree for 3.4.

Most probably we won't be merging everything, which might cause trouble
when merging the localizations as a whole :-(

 In that case yes, we want the l10n repo merged and containing all the 
 new features or fixes strings from OOo. And the sooner the better 
 whatever the amount of strings :-)
 So that means that we can extract the strings from the last OOoDEV and 
 merge them with our LO file to have the complete (UI+HC2) set of strings 
 up to date until now?

Based on what you wrote, I think for LO master (towards-3.4), the best
would be to extract all the strings from the current git repositories
(ie. from the LO master branch, not from OOoDEV) to have the complete
set (so that it would look similar to what is in the OOo Pootle now, but
based on LO sources), and msgmerge the translations from OOo and from
lo-build.po.  That way, it would be easy to merge updated translations
from OOo later (should there be any), while still having the LO strings
as the base.  Or are there reasons not to do that?

BTW - would it help you if we got rid of the sdf files, and instead we
had .po files in the l10n git repository?  [For sure it would help us
who work with the git repos, because the sdf file format is just
something incredibly terrible for version control.]  Would you be able
to merge directly from the OOo Pootle, or from .po files produced by
that, or do you still need .sdf for part of your workflow?

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/l10n/
*** All posts to this list are publicly archived for eternity ***

Re: [libreoffice-l10n] Re: Embedded parts and wikihelp/HC2

[Jan Holesovsky]

Hi Martin,

On 2010-12-16 at 19:08 +0100, Martin Srebotnjak wrote:

  We can easily show a suggestion to download a localized version of the
  help on each and every page, if the language is not en_US.  With your
  help (the l10n team), this can be even shown in the native language of
  the user, with a direct link to the download location.  How does that
  sound?
 
 While that would also be nice to have, I think it is mandatory to explain
 that during installation. And at the end of installation it would be nice to
 have a link to download the language pack. At least for Windows and OSX,
 that have a GUI installer.

I've just seen the test installation of the future LibreOffice site; I
think it very much fulfills what you are proposing.  It is not at the
end of the installation, but at the time you are downloading
LibreOffice:

http://test.libreoffice.org/download/

If you choose Linux version, you can choose the language version you
need, as an additional download.  I suppose the same will be implemented
with the Windows version after the RC2 that will have the langpacks.

I hope this resolves even this concern :-)

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***

Re: [libreoffice-l10n] Re: Embedded parts and wikihelp/HC2

[Jan Holesovsky]

Hi Sophie, all,

On 2010-12-16 at 18:07 +0300, Sophie Gautier wrote:

  How does that sound?  If this plan is acceptable for all, I can go
  ahead, and start working on this :-)
 
 For me it is, and I think that every body will the happy with your 
 proposal. Thanks a lot :-)

I have just updated the wiki accordingly:

http://wiki.documentfoundation.org/Development/Wikihelp

Please double-check, I hope I did not forget anything :-)

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***

[libreoffice-l10n] Re: Embedded parts and wikihelp/HC2

[Jan Holesovsky]

Hi Sophie,

On 2010-12-16 at 07:38 +0300, Sophie Gautier wrote:

 I've two questions concerning the wikihelp/HC2, there is no emergency 
 for the answer, I know you're busy, but I don't want to forget to ask ;)

We are all busy, I am sure; thank you for the explicit CC:, it is then
much easier to give this the priority it deserves! :-)

First of all - thank you all for the input on the wikihelp.  This is
software, so any [or at least many ;-)] changes are of course possible.
So far, it seems to me that what Martin proposed fits all the [in
alphabetical order] developers, documentation team, and l10n; I mean:

- 8 -
I propose you develop a system to have English help editable on wiki but
fully transportable back to the po/xliff system (interchangeable).
All the translations would start from the English po/xliff help files
and decide whether to
a) strictly translate English help (like we Slovenians decided) and keep
working with po/xliff files; the online help would be updated from these
files at least with every minor and major release;
or
b) develop their own help in the wiki and never go back again;
- 8 -

To summarize that, the best seems to be that:

- only the English pages will be editable
  - like eg. http://help.libreoffice.org/Common/Save_As
  - but the lang versions, like
http://help.libreoffice.org/Common/Save_As/cs
will be _not_ editable

- strings from the English pages will be uploaded to pootle
  - so that you can work the way you are used to

- existing translations will be converted
  - so that the work is not lost, ie. everything that has been
translated so far has to be translated in the wikihelp version too

- the pootle tranlations will be applied over the English version
  - but if a language team decides that they want to translate directly
in the wikihelp, their language version will be open for editing
directly in the wikihelp

How does that sound?  If this plan is acceptable for all, I can go
ahead, and start working on this :-)

Only one problem I can think of is the time; I am not sure if I can get
that 100% before the final release, so - it might happen that the
wikihelp will be English only at the time of 3.3 final, but filed with
the translated versions as soon as the above works (but it is an online
thing, so the deployment can be independent of the release date, there
is still room for improvements).  We will have the translated helppacks,
so hopefully it is not an issue. 

 Currently in the HC2 files, pages are composed by a mix of embedded 
 chunks and local strings. We use two files to get the KID of the string, 
 to display the embedded chunks, the .xhp tree and the OS dependent parts 
 in order to do l10n QA on the files.
 
 I've added a screen shot of the result to my page on the wiki [1].
 
 How somebody contributing to the wikihelp will see these embedded parts 
 or OS specific parts. How will he knows that it should not make it to 
 much particular to a certain page because it will appear elsewhere on 
 other pages in the HC2?

This is a very good question.  In the current implementation, I do not
treat embedding in a special way, and just copy the text there directly.

The following is the page you have shown on the screenshot:
 
http://help.libreoffice.org/Writer/Shortcut_Keys_for_Writer 

Ie. the 'Some shortcut ...' text is directly there, not an embedded
string.

If we want to address this, it is of course solvable too; the only
problem might be that for everything that is supposed to be embedded, it
has to have a special page, like Embed:Some_id, an in the text, it would
be used like {{Embed:Some_id}}.

For example, a text like:

file swriter/file1.xhp:
  paragraph ...variable ...somethingSomething to
embed/variable/paragraph

file swriter/file2.xhp:
  embed href=...file.xhp#something

would in the wiki look like:

Page Embed:file1_something
  Something to embed

Page Writer/file1
  {{Embed:file1_something}}

Page Writer/file2
  {{Embed:file1_something}}

Documentation team - is that acceptable for you?

OS specific parts are already solved differently, there is a template
{{System}}, used like {{System|mac=Mac string|win=Windows string|
default=something default}}.

The template page itself does not work yet (ie. always the default
choice is shown), but I'll fix that ASAP.

 Some pages are mostly composed by embedded chunks, if those embedded 
 part are removed, would that mean we will have to duplicate the 
 localization?

Yes, they would have to be duplicated, if the {{Embed:...}} solution
outlined above is not acceptable (though I hope it is).

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***

Re: [libreoffice-l10n] Re: [Libreoffice] LibreOffice WikiHelp

[Jan Holesovsky]

Hi Martin,

On 2010-12-14 at 12:27 +0100, Martin Srebotnjak wrote:

   I think the biggest issue is the offline editing; and I think here we
   can use the Wiki Publisher
   (http://extensions.services.openoffice.org/project/wikipublisher)  to
   edit the pages in LibreOffice.
[...]
 I believe that is not a good idea. It will reformat the content and make
 changes tracking a nightmare. Also, translating from changed US wiki to
 other languages will be a nightmare.

Let's see - as I said, so far I haven't done any testing, to see how
good it is; I can imagine it works just well, and of course, even the
opposite scenario :-)

 I propose you develop a system to have English help editable on wiki but
 fully transportable back to the po/xliff system (interchangeable).
 All the translations would start from the English po/xliff help files and
 decide whether to
 a) strictly translate English help (like we Slovenians decided) and keep
 working with po/xliff files; the online help would be updated from these
 files at least with every minor and major release;
 or
 b) develop their own help in the wiki and never go back again;

Yes, this seems so far working for most :-)  I'll make sure that all the
work you've done on the the help translation so far is not lost.

 Before I go on I need an answer to a question. I tried the help in RC1 and
 it seems that help items do not get passed to wiki i.e. the default module
 help page opens even if you press F1 in a certain dialog (the previous
 bundled help showed that definite topic in the help).

This is a blocker bug, already reported as:

https://bugs.freedesktop.org/show_bug.cgi?id=32338

It works in some of the scenarios (eg. in the menus), but not in the
dialogs.  I am working on it, this is of course not intended.

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***

[libreoffice-l10n] Re: [Libreoffice] LibreOffice WikiHelp

[Jan Holesovsky]

Hi Sophie,

On 2010-12-11 at 14:35 +0300, Sophie Gautier wrote:

  I have heard quite some complaints about the missing native language
  versions already; I am not sure I've explained it well enough
  previously, but this testing is blocking it.  So please - help me :-)
 
 I've search for your explanation on our list but didn't find them. 
 Currently we (the localizer team) do not want the localized help to be 
 uploaded on the wiki until we know about the localization process that 
 will be in place.

I have subscribed to the l10n mailing list just on Friday, after I
learned that there were some discussions there I was not aware of until
then.

Now, the explanation about wikihelp.  As you may recall, the conclusion
was described as:

create help-packs - split out the help for each language
and simply have no help installed[1], but a web link to on-line
help[2], and a download your help-pack here direction
+ not even English help would be installed -
  this will save us 11Mb in the 170Mb download

Also, each and every release notes of betas and even RC1 contained a
note The help content is not included. We are working on the online
version. Alternatively, it will be possible to install it separately.

It is my mistake that I did not explain the exact way to implement it in
advance, I am sorry for that.

So let me explain why wikihelp:

Wiki is so far the best free tool for collaboration editing I know of.
It gives anyone the freedom to improve things.  With help implemented as
a wiki, any user of the suite can (potentially) just describe the
functionality better, should he/she find out that something is described
wrongly, or just partially.

Also, why should be your native language just a translation of an
English help?  Should you have people that can improve the help, but
cannot speak English, why should they be bound to translating only, when
they can author the text?  Why should be the French help just a
translation of an English help, when it can be an own (better?) version?

This is why I believe implementing the help as a wiki is the best thing
to do.  How does it work:

- for 3.3, I am converting the .xhp files into wiki markup
  - it is now online as http://help.libreoffice.org
  - missing translations yet, I need to polish the tooling first
  - when the tooling is right, I'll add 2-3 more languages, for more
testing
  - when even that approved, I'll upload the rest

- anything untranslated in the localized versions will be marked
  appropriately
  - a template for that, like {{NeedsTranslation}} + the English version

- after the import is done, and people are happy with it, it will be
  open for account creation
  - for now, please ask me directly if you want to have an account
there, to edit pages like Main_Page, or Template:*
  - other pages might get rewritten by the import tooling

- after 3.3, I'll start to work on tooling to convert it back to offline
  help
  - to platform native help system
- Windows/Linux/MacOSX
  - from the engineering point of view, we don't want a home-grown help
system, as we have now
  - needs more research, to see if we don't lose features etc.

- when done, the wikihelp becomes the authoritative version of the help
  - but we'll still be able to incorporate changes from the .xhp files,
when merging from OOo
  - we can agree that some of the localized versions would be locked for
editing, and just taken from .xhp and .sdf files, but I _strongly_
advise against that

Open questions:

- extended tips
  - cannot be part of the wikihelp, most probably these have to be
handled separately, and translated using the normal process

- anything else?

 We are the one doing the work and it's a very big work, so please, 
 answer the questions we have asked.
 What if we open the git repository to anybody tomorrow?

As you might have noticed, anybody can ask for the git account, and
anybody with a bigger contribution is offered with write access.

  will you stay 
 there and spend your nights correcting the bugs newcomers have done or 
 those not taking care of your previous work?

Oh?  Were you following what we are doing on the development mailing
list?  The last months, we have spent days and nights reviewing and
fixing patches from new people.

  No, you'll go away from 
 such a project that do not care about your contributions and the quality 
 of its product.

Why do you think that people want to break your work?  Do you really
think that making something yourself is more effective than just
reviewing someone else's work?  How could it scale, if you were doing
everything yourself?

 So please, please again, answer the questions Martin asked, the 
 questions I asked, see Rimas and Jean-Baptiste mails too. And do not 
 open the wiki until we all agreed on the workflow, it's really important 
 for our localization team.

Yes, will do, and sorry again that I haven't summarized all this 

[libreoffice-l10n] Re: [Libreoffice] LibreOffice WikiHelp

[Jan Holesovsky]

Hi Sophie,

On 2010-12-13 at 14:05 +0300, Sophie Gautier wrote:

  I have subscribed to the l10n mailing list just on Friday, after I
  learned that there were some discussions there I was not aware of until
  then.
 
 This is the list for the people doing the work you're currently 
 removing, so you should have come first to this list :-)

I hope I am not removing anyone's work; I just want to change the
workflow a bit, hopefully for better :-)  And also yes, this is not set
in stone, there are several prerequisites for the last step (wikihelp
being an authoritative source for the help) that clearly depend on you -
the translators and documentation writers.

There are many technical solutions possible, including uploading the
English wikihelp pages to pootle (so far it is done per paragraph
anyway), and having chosen languages read-only in wikihelp, generated
from the English version + pootle.

  Also, why should be your native language just a translation of an
  English help?  Should you have people that can improve the help, but
  cannot speak English, why should they be bound to translating only, when
  they can author the text?  Why should be the French help just a
  translation of an English help, when it can be an own (better?) version?
 
 This is all the difference between documentation and the help. Creating 
 content is much more difficult than translating it and doesn't have the 
 same cost. So offering the help files for translation ensure that all 
 languages have access to the same basis of *accurate* information. This 
 is what Help is and why it should stay in a localization process.

Maybe I am entering a thin ice here, but do not think we have a good
help as of now.  There is so few information there, in many times in the
form 'Insert Picture' functionality inserts a picture from a file. ;-)

We need to grow the family of the documentation writers, and we cannot
do that by using the current tools.  Authoring the .xhp files as we have
now has a terribly steep learning curve (see the description of the xml
language that is used for that, or the description of how to use the
extension for the help authoring
http://documentation.openoffice.org/online_help/helpers/helpauthoring/guide/OOo2HelpAuthoring.pdf).

So we need to do the work easier not only for the translators, but for
the help authors, or the documentation team in general, too.  And I
believe that with wiki, this has the biggest potential to scale.

 Offering the same information at the lowest cost as possible.
 If it needs to be completed, lets do it as we have done until now : 
 using links pointing to the wiki (see the Calc functions, as an example).

I am sorry I haven't stressed this enough still: For 3.3, I am just
importing the help to the wikihelp, there is no change in your
processes.

 Just an example : we often have to correct one string in the UI, to make 
 sure it's changed in all the files where this string is appearing, we 
 just grep and change the string. You won't be able to do that on a wiki. 

It is again solvable, it is easy to provide dumps of the wiki (believe
it or not, bzipped it has only about 1.4M per language), for the offline
grepping.

 Also we make large use of suggestions and comments on strings, we work 
 off line, we use translation memory and glossaries, etc. All these 
 tooling ensure a quality of our work that you won't be able to use on a 
 wiki.

I think the biggest issue is the offline editing; and I think here we
can use the Wiki Publisher
(http://extensions.services.openoffice.org/project/wikipublisher)  to
edit the pages in LibreOffice.  I did not test it yet, but if the
extension misses the functionality to merge the changes done in the
wiki, it will be easy to plug it to LibreOffice document merge feature.

  As you might have noticed, anybody can ask for the git account, and
  anybody with a bigger contribution is offered with write access.
 
 with bigger contribution it is different from a wiki where anybody is 
 able to create an account and start to work.

It is just up to the wiki setup - we can of course have a group of
admins who will be giving rights just to the selected people, etc.

 yes, provided you can discuss with this people, on a wiki, you just 
 create a account and can stay anonymous, unfortunately. Really, all the 
 l10n teams have spent nights on these files, we wouldn't like see them 
 destroy by a bot.

Understood - please see my other mail to JBF about fighting spam.

 No you misunderstand what I say, reviewing is the same for me,

I see, OK.

  but a 
 wiki is just open to every body without knowledge of stylistic, 
 linguistic, and so on.

No, it does not have to be open to everybody, even the account creation
can be restricted to selected group of people only.

 Most of the time I've posted also on the dev list, so you may not have 
 miss mine. But surely, Martin and Rimas one. I'll try to find them when 
 I can reach the archives of the list.

Sorry, I missed 

[libreoffice-l10n] Re: [Libreoffice] HC2 l10n process

[Jan Holesovsky]

Hi Sophie,

I am sorry for missing this mail :-(  Please cc: me explicitly the next
time.

On 2010-12-08 at 14:34 +0300, Sophie Gautier wrote:

 So, some inputs from the localizer point of view concerning the help files.
 Currently, it's not available else than on line and in English, which is 
 very problematic, and more for some of us who received support to make 
 it available, plus it let think that it is not translated at all. So, as 
 Martin said on the l10n list, it's currently a stopper for localized 
 builds if the help is not available aside the product and in its language.

Yes, the availability of the off-line help was one of the requirements
from the very beginning, and it hasn't changed.

 Out of this, if we further your effort to put it on the wiki, what the 
 localizer need is:
 - an offline way to work on it

It should be easily achievable using Wiki Publisher extension.  And if
it has a missing feature or 2, that is fixable, and users will gain by
that too :-)

 - the ability to grep the strings (we frequently make changes in UI that 
 we need to report in the several places where the word appears in the 
 help files)

With wikihelp, you can search there, google there, and if you need that,
I can also provide snapshots of the entire content - one language takes
1.4M bzipped, so a trivial download.

 - the ability to add comments to the segments

You can add comments as !-- comment -- inside the pages, also you can
have Talk: pages to the 'master' ones that include discussions, etc.
Anything missing there, please?

 - the ability to make proposal only and accept those proposal,

This is another use for the Talk: pages.  Please see
http://en.wikipedia.org/wiki/Help:Using_talk_pages

 - the ability to use automated checks, such as end punctuation, start 
 caps, sentence count, extra blanks, etc.

Can I have exact list of what you are using currently?  I am sure that
for many such things there already exist Mediawiki extensions, it is
just a matter of installing them.

 - of course the use of terminology file to ensure that UI strings are 
 the same in HC2.

This is something I cannot force, I am afraid, this really needs to be
part of your workflow.

 This is the most important actions I see, may be others may have 
 additional requests.
 If you make sure that those needs are met, we will be able to work on it 
 and provide the same level of quality we are currently providing for our 
 localization.

I hope this answers your questions.

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***

Re: [libreoffice-l10n] Re: [Libreoffice] LibreOffice WikiHelp

[Jan Holesovsky]

Hi Martin,

On 2010-12-11 at 08:56 +0100, Martin Srebotnjak wrote:

 you really do not expect us to edit/translate the help via wiki? To
 have wiki as the main localization infrastructure?

I think it has many advantages to do that, but if it does not work for
you, it is possible to implement the possibility to make your language
read-only, with pootle being source of the translations.

Regards,
Kendy


-- 
Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org
List archive: http://www.libreoffice.org/lists/l10n/
*** All posts to this list are publicly archived for eternity ***

Re: [libreoffice-l10n] Translation scope

[Jan Holesovsky]

Hi Petr,

On 2010-11-01 at 18:00 +0100, Petr Mladek wrote:

 PS: Of course, we need to find more clever strategy after LibO-3.3.

Yes - get rid of .sdf ;-) - it is just terrible for _any_ SCM.

Regards,
Kendy


-- 
E-mail to l10n+h...@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/l10n/
All messages you send to this list will be publicly archived and cannot be 
deleted