[documentation-dev] Toggle Display back in the Wiki
I've added ToggleDisplay back to the Wiki. The rpoblems we had with this extension and the older MediaWiki engine have been resolved, and the extension is working correctly now (also being used on WikiPedia, so it should be stable enough for our use as well). http://www.mediawiki.org/wiki/Extension:ToggleDisplay C. -- Clayton Cornell ccorn...@openoffice.org OpenOffice.org Documentation Project co-lead StarOffice - Sun Microsystems, Inc. - Hamburg, Germany - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
[documentation-dev] Page rating extension on the Wiki
A while back, the UX project requested that we install an extension that would allow users to rate or rank a page. There were problems with the previous MediaWiki engine that prevented us from rolling out this extension - those problems were corrected with the most recent MediaWiki upgrade, so this extension is available again. See http://www.mediawiki.org/wiki/Extension:JSKitRating for documentation/info on this extension. Maybe this is something we could use for FAQ pages? or other pages? C. -- Clayton Cornell ccorn...@openoffice.org OpenOffice.org Documentation Project co-lead StarOffice - Sun Microsystems, Inc. - Hamburg, Germany - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
Re: [documentation-dev] [Fwd: [authors] fm for Macintosh or UNIX available cheap]
BTW, FrameMaker 7.0 is available for the Macintosh. And recent UNIX versions of FrameMaker are also available. Anything in the FM7 series should be cheap via eBay. FrameMaker 8 or 9 would not be necessary for DocBook, as even the ancient (still used in some houses) pre-2002 FM 6 would suffice. UNIX isn't Linux. Do any versions work on Linux? When you say cheap, what approximate price do you mean? Can people outside the US also get FM cheap? The last FM for Linux was FM 5.5.6 (I might even still have a copy around... somewhere). Since then they've dropped all support for Linux, and shifted their primary focus to Windows. The last FM for Apple was 7.0 for MAC OS9 - they did not make/release an OSX version. You could run it in compat mode (or whatever it is called on older OSX versions) but that is no longer possible from what I've been told with the latest OSX releases. Solaris support was dropped for FM9. So... in my opinion - even though I really like FM, and have used it a lot in the past for tech writing - FM is not really the route I would support for any OOo documentation. Mixing in other editors into a FM environment (in my experience) is complex and full of problems. None of the other editors I've used fit well into a FM-centric workflow. A single editor and a single/simple workflow for that editor is a lot more manageable. It's been awhile since I looked for free or cheap XML editors so perhaps things have changed. In my experience, the free or cheap ones were far from easy to use for anyone not familiar with, and comfortable working with, XML code. Any program that provided a reasonably WYSIWYG front-end, and was therefore easy to use, was expensive. If something that fits my criteria has shown up in the past year or so, I would genuinely like to hear about it. That still applies. There are many good free editors, but they generally require the author to work in the raw XML code. Barriers may not be insurmountable, but they are still barriers. And even if we all thought your idea was the way to go, *someone* would have to lead the rest of us by the hand, in order to implement the idea. I agree with Jean 100% here. I like DocBook, and think it's a very powerful tool, but... it also requires a very high level of technical expertise to work with and more importantly.. maintain it. Who develops and maintains the exports and transforms? Do we use Ant scripts? Who maintains the XSLTs? Do we use XML-FO for PDF output or something else? and so on... My concern is that the technical and edit barrier is so high with a DocBook process that, at this point anyway, we loose too much on the author editing side and it outweighs the benefits of DocBook. C. -- Clayton Cornell ccorn...@openoffice.org OpenOffice.org Documentation Project co-lead StarOffice - Sun Microsystems, Inc. - Hamburg, Germany - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
Re: [documentation-dev] Re: [l10n-dev] Massive English help stampedo
TJ, Providing automated cleanup tools is one of the things I enjoy doing for the Documentation Project. The major tool I use is Writer: people tend to forget that our flagship word processor is a fine and powerful text editor, too. Add a little bit -- or a lot -- of Basic code, and one can accomplish almost anything, with text documents. And, by definition, it runs on any supported platform. You may be surprised but we do actually use Writer to produce the help content. We are using special import and export filters to load and save the xhp. This includes a set of Basic scripts to control the output, see http://documentation.openoffice.org/source/browse/documentation/www/online_help/helpers/helpauthoring/ (I am currently updating the files) Writer handles XML, and HTML 3.2 Help files, just fine, as ordinary text. It's not as pretty, for humans, as specialized editors would be, but Basic doesn't care. Specifically, getting rid of the 6-blanks strings in the CWS should be easy, assuming that there are no legitimate instances of such a thing. Any such validation must be based on rules, we need to define so we do not by accident fix bugs that are no bugs. Some come to mind: - No trailing spaces in a paragraph - No empty elements except for br/ - Adjacent elements need to be merged: emphOne/emphemph Two/emph - emphOne Two/emph If the files are (or can be) laid out in a hierarchical set of directories, the way the Help files are when a source tar-ball is unpacked, then I can scan all the files in one operation, processing each one, and save the output in place, or to a parallel set of directories. [...] If anyone is interested in this approach, please let me know (on dev-doc). --/tj/ Ultimately, I guess we need to make this part of the help authoring cycle, adding that validation/normaliation either to the helpauthoring extension for OOo, or as part of the module build. Frank -- Frank Peters x66757 Learning and Publications Manager SLS - CCLS Application Services Office Productivity Communication Suite Sun Microsystems, Hamburg - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
Re: [documentation-dev] Announcing translated phrases in MasterTOC template
On 09/06/09 11:44, T. J. Frazier wrote: User Nnino and I have completed the automated translation of the phrases displayed by the template, MasterTOC (Next page, for example). The template now processes a new parameter line, |Lang=XX, where XX is the (case-sensitive) ISO code for the desired output. This defaults to Lang=en, so no changes are required in existing calls. For wiki-documents that use chapter templates, the Lang parameter goes in those templates, where they call MasterTOC, rather than on each page. In order to provide translated phrases, an auxiliary template for the language code must be created. As of this announcement, only two are available: English (en) and German (DE). See [1] for an up-to-date list. See [2] for instructions on creating a new template. Please report any problems on this list. --/tj/ [1] http://wiki.services.openoffice.org/wiki/Category:Documentation/TOC [2] http://wiki.services.openoffice.org/wiki/Template:Documentation/TOC/TOC_en Looks great :-) Has this also been announced on the L10N mailing list? That's were most of the translators hang out. C. -- Clayton Cornell ccorn...@openoffice.org OpenOffice.org Documentation Project co-lead StarOffice - Sun Microsystems, Inc. - Hamburg, Germany - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
[documentation-dev] Re: [l10n-dev] Massive English help stampedo
On Mon, Sep 7, 2009 at 11:52, Frank Petersf...@sun.com wrote: Martin, Apparently, those changes came in by error. So we need to evaluate how that happened and how it can be prevented in the future. Accusing co-contributors of being malicious or inconsiderate will certainly not facilitate this effort. So, please, (and I am minding my tone), who did these changes? Who is In what way do persons matter here? responsible? Who did QA? This did already happen some milestones ago I was not aware of this. Has this been reported before when you first noticed it? This was reported 9th July after m51 milestone in d...@docs list by Hristo Histov (to be honest he asked me and I suggested him to write to list): http://documentation.openoffice.org/servlets/ReadMsg?list=devmsgNo=5573 ain - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
Re: [documentation-dev] Page rating extension on the Wiki
On 09/07/09 10:08, ccornell - OpenOffice.org wrote: A while back, the UX project requested that we install an extension that would allow users to rate or rank a page. There were problems with the previous MediaWiki engine that prevented us from rolling out this extension - those problems were corrected with the most recent MediaWiki upgrade, so this extension is available again. See http://www.mediawiki.org/wiki/Extension:JSKitRating for documentation/info on this extension. Maybe this is something we could use for FAQ pages? or other pages? As a test, I added the page rating code to this FAQ page: http://wiki.services.openoffice.org/wiki/Documentation/FAQ/General/How_do_I_open_Microsoft_Office_2007_files%3F C. -- Clayton Cornell ccorn...@openoffice.org OpenOffice.org Documentation Project co-lead StarOffice - Sun Microsystems, Inc. - Hamburg, Germany - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
[documentation-dev] Re: [l10n-dev] Massive English help stampedo
Martin, 2009/9/7 Frank Peters f...@sun.com: So, please, (and I am minding my tone), who did these changes? Who is In what way do persons matter here? Well, up until now this did not happen. Actually I do remember some sporadic errors like added 6-blanks in the past year, maybe 5 of them in several unrelated spots, but thought that is a small typing error and didn't care about it. But then came m51 (and now m57). Obviously something changed in the last few months. Either they changed the tools for editing the help or someone not aware how to use the tools properly did something wrong. Knowing who it was is the way to eliminate such errors from any future changes in help (at least the added blanks). The history of these errors is that Uwe has been using the OOo helpauthoring framework to modify help files until a bug in this framework prevented him from doing so, so he had to switch to a different editor that apparently tried to beautify the XML code responsible? Who did QA? This did already happen some milestones ago I was not aware of this. Has this been reported before when you first noticed it? I noticed it in m51, and immediately reported to head of Slovenian localization, Robert Ludvik, who check some mailing lists (maybe this one) and reported to me back, that it was already reported. He probably meant the report Ain quoted. Yes, and Uwe replied and gave the root cause for this, thinking that the root cause was removed which apparently was not the case. The editor used for the help is actually OOo. Unfortunately, it seems like it leaves residual tag fragments when deleting tag content, or does not merge tags on adjacent content. For the future we need to implement more checks or normalization steps to make sure that this doesn't happen. Using CVS for documentation content doesn't work very well by principle, after all. Up until m51 this did not happen. And probably you were using it for years. What changed in OOo or the team using it in the past half year? There the answer lies. Maybe it would be beter to use the good old 2.4 for editing help, because since 3.0 some automagic or filter changes were introduced that mess with the files ... No, the bug has been identified and fixed that prevented Uwe from using the helpauthoring environment in OOo. So we should be back to normal. I must take partial responsibility since I did not fix the helpauthoring bug soon enough. The bug itself arose due to changes in how OOo wrote ODT. Anyhow, we need to find some mitigation for this. What options do we have assuming that extending the l10n deadline is not one of it? Can you provide a list of all files that contain these errors and that have not been localized, so we can see whether we can rollback the changes there (but not at places that you already localized) for the next (and for 3.2 final) help CWS hcshared23. It is hard to locate and list them all. In files where under 100 of those changes are located, we can do it somehow manually and you will clean this mess up later. Mostly affected files are (as far as I can tell) three, but in a different way: mostly added blanks: helpcontent2/source/text/scalc/01.po (around 280 changed strings) mostly changed tags, like emph - item type=\menuitem\ helpcontent2/source/text/scalc/guide.po (around 230 changed strings) changed tags, like emph - item type=\menuitem\ with some added blanks helpcontent2/source/text/swriter/guide.po (around 1000 changed strings) (this file obviously has also some or many textual changes, I would say) shared/00.po has around 100 changed/new strings, but they are mostly img tags, so not a lot of work for translator, this can remain as is. So the first three listed files represent around 1500 changes out of 1950 or so of the m57. If you can clean those three files of unwanted blanks and undo the tag change, with old po files of the same name updating them to new pot's the translators will get a true picture what content was edited and needs to be changed/translated. I don't know about PO files. Uwe can try to roll back those changes in the sources so that the next po files get updated accordingly. OT: with all these icon (img tags) changes or additions, and I do not want to start a flaming war here, I see mostly inches are still used, although inches are officially used in only three countries today - the U.S.A., Myanmar and Liberia, I think. Is there any particular reason for this? I guess changing that to metric system would cause same massive help changes, so, no, I do not propose to change all inches to centimeters :) This, too, is a side-effect of the implementation of the help authoring environment. The value written depends on what language version of OOo you work on. I think, ultimately, we could just leave that out entirely since it's currently not used (no, not retroactively, just for new images) Frank -- Frank Peters x66757 Learning and Publications Manager SLS - CCLS Application Services Office
[documentation-dev] Re: [l10n-dev] Re: [documentation-dev] Re: [l10n-dev] Massive English help stampedo
Martin Srebotnjak wrote: 2009/9/7 Frank Peters f...@sun.com: Specifically, getting rid of the 6-blanks strings in the CWS should be easy, assuming that there are no legitimate instances of such a thing. Any such validation must be based on rules, we need to define so we do not by accident fix bugs that are no bugs. Some come to mind: - No trailing spaces in a paragraph - No empty elements except for br/ - Adjacent elements need to be merged: emphOne/emphemph Two/emph - emphOne Two/emph [...] But what worries me most (I guess the blanks can and will be taken care easily) are massive change of tags like: emph - item type=\menuitem\ I can only get a heart attack thinking if what just now happened in helpcontent2/source/text/swriter/guide.po (there were around 1000 changed strings out of 2100, mostly with these tags changed and some 6 or 9-blanks added) would happen to other help files. There would be 10.000's strings that all translators would need to manually edit. The emph item change, I cannot explain. I will talk to Uwe how this could have happened. [...] Please, keep this in mind when you decide what to do with changes in m51 and m57 and further steps in changing tags in these files. Changing 2000 help strings, some intentionally by just replacing tags and some by mistake of adding blanks mean same as 2000 new untranslated strings. I doubt that Uwe intentionally replaced 1,000 tags. He does this job for more than a decade now and he is well aware of the effect this has on localization. So if such tag changes are planned, a special CWS could be created, where *all* such tags should be replaced, then all current SDF files from all translation teams should be delivered by the translation teams to Hamburg where they would use this special super-trouper command line tool that would replicate all the tag changes in translations as well (this would most probably be an error prone procedure, but at least it would change most of the changes correctly; I guess 95% success would be more than enough, if those error likely strings would get marked as fuzzy). Then CWS would be published in an mXY and teams would get their SDF-po files back and continue their business as usual. If that is possible. Yes, absolutely, and I have raised this approach before. Such generic changes should be done on source and SDF automatically. Frank -- Frank Peters The OOo Documentation Project: SIGN UP - PARTICIPATE - CONTRIBUTE IT'S FREE! NO OBLIGATIONS! http://documentation.openoffice.org http://wiki.services.openoffice.org/wiki/Documentation - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
[documentation-dev] IMPORTANT: Helpcontent changes in m57
As reported by Martin, Ain and others helpcontent2 introduced
numerous changes partly due to a bug in the creation tools and
partly due to communication issues. As far as I understood,
these changes affect the following:
1. Replacement of emph by item type=menuitem elements
2. Occurrence of extra, multiple spaces, sometimes trailing
3. Icon alt text says {ENTER ALTERNATIVE...} instead of icon
We apologize for the inconvenience this is causing and would
like to learn from you how to resolve this issue.
We need to know if we should roll back the changes listed
above that were introduced with m57 (this does not apply
to the relevant content changes, just the changes
listed above).
*It's important that we get feedback by tomorrow, or else
our deadline fort the last help cws runs out*
After this release, we'll start a discussion on how
to efficiently clean up the source code without
l10n impact (e.g. getting rid of the image size attributes).
Thanks
Frank
--
Frank Peters
The OOo Documentation Project:
SIGN UP - PARTICIPATE - CONTRIBUTE
IT'S FREE! NO OBLIGATIONS!
http://documentation.openoffice.org
http://wiki.services.openoffice.org/wiki/Documentation
-
To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org
For additional commands, e-mail: dev-h...@documentation.openoffice.org
[documentation-dev] Re: [l10n-dev] IMPORTANT: Helpcontent changes in m57
Hi Translators/Localizers,
On 09/07/09 14:50, Frank Peters wrote:
As reported by Martin, Ain and others helpcontent2 introduced
numerous changes partly due to a bug in the creation tools and
partly due to communication issues. As far as I understood,
these changes affect the following:
1. Replacement of emph by item type=menuitem elements
2. Occurrence of extra, multiple spaces, sometimes trailing
3. Icon alt text says {ENTER ALTERNATIVE...} instead of icon
We apologize for the inconvenience this is causing and would
like to learn from you how to resolve this issue.
We need to know if we should roll back the changes listed
above that were introduced with m57 (this does not apply
to the relevant content changes, just the changes
listed above).
*It's important that we get feedback by tomorrow, or else
our deadline fort the last help cws runs out*
I agree with Frank that it is important to get your feedback and your GO
before we roll back the changes/issues listed above.
Thanks,
Rafaella
-
To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org
For additional commands, e-mail: dev-h...@documentation.openoffice.org
Re: [documentation-dev] Page rating extension on the Wiki
On 09/07/09 14:35, Nino Novak wrote: On Monday 07 September 2009 10:08, ccornell - OpenOffice.org wrote: A while back, the UX project requested that we install an extension that would allow users to rate or rank a page. Nice! We should look for some nice seagull icons replacing the stars :-) I experimented with that a bit... it didn't work so well :-) There is an option imageurl=someurl that you can use, but doesn't seem to work with regular png images. I was able to set a color though using starColor=blue and it matches a bit nicer to the overall OOo color scheme. This is a per instance option, and needs to be set each time the rating extension is used. C. -- Clayton Cornell ccorn...@openoffice.org OpenOffice.org Documentation Project co-lead StarOffice - Sun Microsystems, Inc. - Hamburg, Germany - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
[documentation-dev] Re: [l10n-dev] IMPORTANT: Helpcontent changes in m57
Hi, Original-Nachricht Von: Rafaella Braconi rafaella.brac...@sun.com We need to know if we should roll back the changes listed above that were introduced with m57 (this does not apply to the relevant content changes, just the changes listed above). I agree with Frank that it is important to get your feedback and your GO before we roll back the changes/issues listed above. I have no probelm with rolling back those changes introduced in m57. As we are working on pootle, we are just doing the translations for m54. as these are partially done, please no not rollback changes from m54. André -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
[documentation-dev] Re: [l10n-dev] IMPORTANT: Helpcontent changes in m57
Hi Andre' On 09/07/09 15:22, Andre Schnabel wrote: Hi, Original-Nachricht Von: Rafaella Braconi rafaella.brac...@sun.com We need to know if we should roll back the changes listed above that were introduced with m57 (this does not apply to the relevant content changes, just the changes listed above). I agree with Frank that it is important to get your feedback and your GO before we roll back the changes/issues listed above. I have no probelm with rolling back those changes introduced in m57. As we are working on pootle, we are just doing the translations for m54. as these are partially done, please no not rollback changes from m54. for the moment, the Pootle content reflects m54. However, once the CWSs with the new feature and contents are integrated and we have a new milestone, we will have to update Pootle with the latest milestone Rafaella
Re: [documentation-dev] Re: [l10n-dev] IMPORTANT: Helpcontent changes in m57
On 09/07/09 15:28, Rafaella Braconi wrote: Hi Andre' On 09/07/09 15:22, Andre Schnabel wrote: Hi, Original-Nachricht Von: Rafaella Braconi rafaella.brac...@sun.com We need to know if we should roll back the changes listed above that were introduced with m57 (this does not apply to the relevant content changes, just the changes listed above). I agree with Frank that it is important to get your feedback and your GO before we roll back the changes/issues listed above. I have no probelm with rolling back those changes introduced in m57. As we are working on pootle, we are just doing the translations for m54. as these are partially done, please no not rollback changes from m54. for the moment, the Pootle content reflects m54. However, once the CWSs with the new feature and contents are integrated and we have a new milestone, we will have to update Pootle with the latest milestone the CWS hcshared22 introduced most of the unwelcome and not intended changes to m57. However, the next and final OOo 3.2 Help CWS hcshared23 will follow in less than a week from now. And we can change things back there in the sources, if this is what the stakeholders in the community want. Uwe -- u...@openoffice.org - Technical Writer StarOffice - Sun Microsystems, Inc. - Hamburg, Germany http://documentation.openoffice.org/ http://wiki.services.openoffice.org/wiki/Documentation http://blogs.sun.com/oootnt http://user.services.openoffice.org/en/forum - To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
