<html>
<head>
<title><br /> >>>> <phrase lang="en">What is DocBook.sml?</phrase><br /> >>>> <phrase lang="de">Was ist DocBook.sml?</phrase><br /> >>>></title>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18828"></meta>
</head>
<body>
<div align="left">Great with translated docs :-)</div>
<div align="left"> </div>
<div align="left">Two comments</div>
<div align="left"> </div>
<div align="left">Maybe it would be useful to workout some type of strategy for handling multi languages. I'm thinking about the e-mail lists. If the documents are multi-lingal users probably will request support in the same languages. Is it up to each language to hold some support on their language? </div>
<div align="left">The scenario I can imagine if there is no strategy is that there will be a lot of questions in different languages on the e-mail list of today.</div>
<div align="left">is that a problem ?</div>
<div align="left"> </div>
<div align="left">The next comment is that the update of the translations should only be a matter when it comes to release. To keep the documentation translation up to date in trunk and branches I think is overkill since discussions in developing issues needs to be in english anyway.</div>
<div align="left"> </div>
<div align="left">/Nicklas</div>
<div align="left"> </div>
<div align="left">2009-10-24 Kevin Neufeld wrote:<br />
<br />
Ah, of course. That certainly would be easier to maintain, but it does <br />
>necessitate consistent xml styles across revisions.<br />
>-- Kevin<br />
><br />
>Paul Ramsey wrote:<br />
>> Another approach to maintenance is to have the language maintainers<br />
>> record a "last revision" number in the readme when they've finished a<br />
>> translation pass. Then the next time they come in, they can generate a<br />
>> diff between that revision and head to see what has changed.<br />
>><br />
>> P.<br />
>><br />
>> On Sat, Oct 24, 2009 at 11:52 AM, Kevin Neufeld<br />
>>
<kneufeld@refractions.net></kneufeld@refractions.net>wrote:<br />
>> <br />
>>> I think it's a great idea. I was noticing when we started the documentation<br />
>>> face lift how docbook does indeed make multilingual support easy.<br />
>>><br />
>>> The only thing is, whenever someone submits a patch to the documentation,<br />
>>> they'll have to remember to record the patch in a documentation bug report<br />
>>> so that someone qualified can tackle the translation to other languages. I<br />
>>> foresee one documentation bug report category for every language we plan to<br />
>>> support.<br />
>>><br />
>>> Cheers,<br />
>>> Kevin<br />
>>><br />
>>> Paul Ramsey wrote:<br />
>>> <br />
>>>> Hi All,<br />
>>>><br />
>>>> I'm at the FOSS4G code sprint today, and have been discussing<br />
>>>> multi-lingual documentation with Til Adams and Daniel Kastl. Given<br />
>>>> that we've had 3rd party translations to fr and pt in the past, it<br />
>>>> would be great to pull the i18n community into the main documentation<br />
>>>> process, by making the docs multi-lingual.<br />
>>>><br />
>>>> This project seems to provide a template for doing multi-lingual<br />
>>>> docbook in unified way, with a minimal amount of duplication (in<br />
>>>> particular, we want to avoid duplicating things like the diagram<br />
>>>> generation and the SQL code examples and so on across translations).<br />
>>>><br />
>>>> http://docbooksml.sourceforge.net/<br />
>>>><br />
>>>> The translations then end up looking like this:<br />
>>>><br />
>>>> <br />
>>>><br />
>>>> The translation blocks can be as granular (as above) or blocked (doing<br />
>>>> whole sections in translation or whole chapters) as you want. So we'd<br />
>>>> probably have different granularity in different sections. Reference<br />
>>>> manual very granular (because there's so much code example and<br />
>>>> parameter stuff that is language-independent) and tutorial sections<br />
>>>> less granular (because there's so many translatable words in blocks).<br />
>>>><br />
>>>> Til is doing some experiments with docbooksml and will show us what a<br />
>>>> working multi-lingual set-up would look like when he gets it running<br />
>>>> (posting a postgis source tarball with the multilingual approach<br />
>>>> implemented that we can download and try). Then we can decide<br />
>>>> how/if/when to integrate it into our working doc system.<br />
>>>><br />
>>>> Thoughts?<br />
>>>><br />
>>>> Paul<br />
>>>> _______________________________________________<br />
>>>> postgis-devel mailing list<br />
>>>> postgis-devel@postgis.refractions.net<br />
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>><br />
>>>> <br />
>>> _______________________________________________<br />
>>> postgis-devel mailing list<br />
>>> postgis-devel@postgis.refractions.net<br />
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>><br />
>>> <br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> postgis-devel@postgis.refractions.net<br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>> <br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
>postgis-devel@postgis.refractions.net<br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>