I just found the complete branch in the subversion system, I was looking
for i10tools not l10tools silly of me.

I will have a look at all the tools and see how complicated it would be to
change.

but first I have a help document to translate (last document of the danish
translation) so we get that reviewed.

jan I.

On 12 October 2012 11:50, jan iversen <[email protected]> wrote:

> I know the feeling of inheriting software and procedures, that is not
> always easy...but also a possibility to clean up. In my experience when you
> have responsibility for a procedure over a very long time, it tends to be
> difficult to change it.
>
> I had a look at the translation table and they are mostly standard
> programs, that can pretty easy be adapted, no big deal. You must be using
> other programs to:
> a) split sdf file to po files
> b) collect po files to sdf file
> c) generate release tree files from sdf file
> or have I overlooked a feature in the source ?
>
> It is true that in old days sun had a proprietary tool (I know it from the
> UNIX line) and I think it is a safe assumption that it worked with sdf
> files.
>
> You are right my proposal is no revulotion merely an evolution :-)
>
> However there is a big difference, today you throw away the po files and
> generate them new everytime, because the projects files are considered the
> originals. Doing this means that translators cannot keep information
> easily. Secondly in my proposal I get rid of the sdf file, which seems to
> be a real unnecessary step.
>
> Having the po files in a source control system, will also make it a lot
> easier to determine changes in the translated part, also during
> translation. Today you only store versions of the regenerated release tree
> files. If the translators works with source control, it is also a lot
> easier to check if files have been proofread/reviewed and compare changes.
>
> I could be fun to try it on a small scale like e.g. convert localize.cxx
> to generate a po file.
>
>
>
>
> On 12 October 2012 11:32, Jürgen Schmidt <[email protected]> wrote:
>
>> On 10/12/12 10:46 AM, jan iversen wrote:
>> > I agree with you at the end of day we need to have a working solution
>> and
>> > that can then over time evolve.
>> >
>> > I have a couple of questions about the process:
>> >
>> > 1) how many (rough number) conversion/extract programs do you have ?
>>
>> DISCLAIMER: I was not responsible for this before ;-)
>>
>> In
>>
>> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/l10ntools/source/localize.cxx?view=markup
>>
>> starting line 49 you can see the extensions of files that can contain
>> localization strings. The second column lists the used tool to extract
>> from these files.
>>
>> It seems that we have 9 tools whereas one tool get called with different
>> options on different extensions.
>>
>> > 2) is the sdf file used solely as an intermediary file to create the .po
>> > files and create the language files used in the different release trees
>> ?
>>
>> Yes, I think so. But I can't say for sure, I think the sdf file was used
>> in the past Sun internally to do the translation, probably with
>> proprietary tools as well. Later it was extended to use Pootle to
>> improve the collaboration with the community.
>>
>> >
>> > I am just thinking about a process like this ?
>> >
>> > -- have a database (or file storage) with all po files for all
>> languages,
>> > INCLUDING one EN-EN, this is the repository. which should be kept under
>> > source control.
>> >
>> > When a new release is made go through the following steps:
>> > a) convert the release tree files to one PO file EN-EN (this would need
>> a
>> > change of the current extract programs)
>> > b) compare the new EN-EN PO file to the existing EN-EN PO file, and
>> create
>> > a delta file (With source control this is quite easy)
>> > c) update/merge the language EN-XX PO files according to the delta file.
>> > (this is a simple modified merge in the source control)
>> >
>> > d) get the changed language files translated, e.g. through the pootle
>> server
>> >
>> > e) convert the translated EN-XX PO files back to the release files (this
>> > would need a change of the current convert programs).
>> >
>> > I think you avoid many problems by defining the project (release tree)
>> > files as generated files and not as original files.
>>
>> isn't it very similar to the process today? Ok we have the sdf
>> conversion step as additional step but the rest seems to be similar.
>>
>> When we have new string to localize, a new sdf files is create and
>> converted to template files for Pootle. The related Pootle project gets
>> updated and merged with the new templates. The result is a not complete
>> translated project with the missing delta. This delta gets translated
>> and the result get converted back in sdf.
>>
>> Pootle works internally with a database and the po files gets synched
>> into the database and back.
>>
>> In pootle you can easy navigate to the untranslated strings and I hope
>> offline tools allow this as well.
>>
>> In the end we would benefit from getting rid of the sdf files because it
>> is one unnecessary conversion step where errors can happen.
>>
>> Juergen
>>
>> >
>> >
>> >
>> >
>> > On 12 October 2012 10:03, Jürgen Schmidt <[email protected]> wrote:
>> >
>> >> On 10/11/12 7:05 PM, Alexandro Colorado wrote:
>> >>> On 10/11/12, Michael Bauer <[email protected]> wrote:
>> >>>> The latest versions of Pootle have a feature called AmaGama which
>> acts
>> >>>> as a cross-OS translation memory. For offline, there's Virtaal.
>> Perhaps
>> >>>> not ideal for mainstream translation work like newsletters and novels
>> >>>> etc but I've found it very efficient for software localization.
>> >>>>
>> >>>> Michael
>> >>>>
>> >>>
>> >>> I like Lokalize for KDE, the shortcuts and different layout makes me
>> >>> work faster on switching from one string to the next. Also has good
>> >>> TM.
>> >>
>> >> We can talk a lot about a new tooling or new format but in the end the
>> >> work have to be done and it is far more complex when you analyze what
>> we
>> >> have and use in the code.
>> >>
>> >> We collect translation strings from various different formats and
>> create
>> >> one big sdf file (en-US) which is used as template for all other
>> >> languages. We convert and split the one big sdf in many pot files.
>> After
>> >> translation the po files are converted back into one big sdf file for
>> >> each language. Several different tools extract the strings from the sdf
>> >> file and create the final target files that can be used in build (xcu,
>> >> property files, help files, ...)
>> >>
>> >> Juergen
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
> --
> Jan Iversen
> ________________________________________________
> Tel. no. +34 622 87 66 19
> jandorte.wordpress.com
>
>


-- 
Jan Iversen
________________________________________________
Tel. no. +34 622 87 66 19
jandorte.wordpress.com

Reply via email to