Re: [l10n-dev] odk breaks while building SRC680_m93
Vijay-Kumar wrote: I am building a default build for 680_m93 on fedora core-2 with jdk1.4.2_06, the build is breaking in odk with the following error: dmake: Error -- `/home/vijay/SRC680_m93_OO/solver/680/unxlngi4.pro/inc/sal/deliver.log' not found, and can't be made cvs update module solenv. The file deliver.pl there was updated to fix this. -- _/|\_ Samphan Raruenrom. signature.asc Description: OpenPGP digital signature
Re: [l10n-dev] adding new ancoding does not work
Hristo Simenov Hristov wrote: On Wednesday 20 April 2005 10:27, Stephan Bergmann wrote: Hristo Simeonov Hristov wrote: On Tuesday 19 April 2005 20:19, Eike Rathke wrote: Hi Hristo, On Tue, Apr 19, 2005 at 10:28:52 +0300, Hristo Simenov Hristov wrote: I think that when I choose my encoding in the dialog, it does not call the method for converting my encoding but calls some default method. Where (in which module, which dialog) did you try it? In Writer I'm opening Text encoded file. I tried with replacing of aImplIBM866ToUniTab with values of aImplMIKToUniTab And when I opened TE file it appears correctly, so this array is correct. The problem is how to figure it out which aImplToUniTab using when I open such file with selected MIK encoding (I added in the combobox needed string to be chosen this MIK encoding) Not sure how the status is today, but there used to be trouble with the association of text labels and RTF_TEXTENCODING_ values in those src files, esp. if you are running a translated (not en-US?) version of OOo. One way to debug this might be to check what calls to Impl_getTextEncodingData (textenc.cxx) are actually made. How can I print text in the console? With printf? Try it out. ;) Yes, printf should work on Unix, at least. -Stephan Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] migrate l10nhelp
David Fraser wrote: Robert Ludvik wrote: How can I get a SDF file in format: ... helpcontent2 ... en-US ... String_in english helpcontent2 ... sl-SI ... String_in slovenian ... This is a good question! :-) I think it would be better to enable localize to leave out the language in the output if the translation is not present. Then oo2po will pick up that no translation is present and will give a blank msgstr. I agree with this one. But given the current situation, I presume it is producing English in the sl-SL lines because your translations haven't been merged. You could merge the sl-SL sdf into the source using localize -m and then extract it again using localize -e, but this will still give you some English strings. I'll try this. If I get it right: localize -m -l sl-SI localize -e -l en-US,sl-SI and this results in SDF format like: ... helpcontent2 ... en-US ... String_in english helpcontent2 ... sl-SI ... String_in slovenian ... if it was migrated translation from 1.x .xhp and ... helpcontent2 ... en-US ... String_in english helpcontent2 ... sl-SI ... String_in english ... if it was *not* migrated translation from 1.x .xhp. After oo2po there would be PO file: msgid String_in english msgstr String_in slovenian msgid String_in english msgstr String_in english First pair of msgid/msgstr is a charm and second is OK - we'll have to check and translate all entries but we should do it anyway. Or you could cat the plain English and plain Slovenian (your version) SDF files together and sort the result, which oo2po should then be able to handle. Note that this may confuse the current release, so please let me know how this works. (It should be OK if you specify the languages on the command line). I'll try this one too. Hope that helps David Thanks -- Robert Ludvik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] migrate l10nhelp
Robert Ludvik wrote: David Fraser wrote: But given the current situation, I presume it is producing English in the sl-SL lines because your translations haven't been merged. You could merge the sl-SL sdf into the source using localize -m and then extract it again using localize -e, but this will still give you some English strings. I'll try this. If I get it right: localize -m -l sl-SI localize -e -l en-US,sl-SI and this results in SDF format like: ... helpcontent2 ... en-US ... String_in english helpcontent2 ... sl-SI ... String_in slovenian ... if it was migrated translation from 1.x .xhp and ... helpcontent2 ... en-US ... String_in english helpcontent2 ... sl-SI ... String_in english ... if it was *not* migrated translation from 1.x .xhp. Yes thats correct After oo2po there would be PO file: msgid String_in english msgstr String_in slovenian msgid String_in english msgstr String_in english First pair of msgid/msgstr is a charm and second is OK - we'll have to check and translate all entries but we should do it anyway. You could use the pofilter tool that comes with the translate toolkit to do this. pofilter -t unchanged orig-po/ check-po/ will give you a set of filtered PO files in check-po containing only the unchanged entries. You can then remove all the msgstr from them manually, and then merge them back. The merging back is a bit complex at the moment ... something like this should work: pomerge -t orig-po/ check-po/ merged-po/ --mergeblanks=yes which will produce a new set of files in merged-po that contains blanks in the place of the unchanged things. You can use diff to compare the folders to make sure... Or you could cat the plain English and plain Slovenian (your version) SDF files together and sort the result, which oo2po should then be able to handle. Note that this may confuse the current release, so please let me know how this works. (It should be OK if you specify the languages on the command line). I'll try this one too. Great, let me know how they work David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] odk breaks while building SRC680_m93
From: Vijay-Kumar [EMAIL PROTECTED] Date: Wed, 20 Apr 2005 15:01:31 +0530 (IST) I am building a default build for 680_m93 on fedora core-2 with jdk1.4.2_06, the build is breaking in odk with the following error: [...] `/home/vijay/SRC680_m93_OO/solver/680/unxlngi4.pro/inc/sal/deliver.log' not found, and can't be made Please update your tree. deliver.pl from module solenv was updated and the tag was moved. -- Pavel Jank Don't patch bad code - rewrite it. -- The Elements of Programming Style (Kernighan Plaugher) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
