discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with Gorm Translate


From: Lee, Seong-Gu
Subject: Re: Problem with Gorm Translate
Date: Fri, 25 Oct 2013 09:56:55 +0900
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0

10/25/2013 02:19 AM, Germán Arias wrote:
> Hi,
> 
> On 2013-10-24 10:04:26 -0600 "Lee, Seong-Gu" <sgleehd@gmail.com> wrote:
> 
>> Dear everyone,
>>
>> A few problems were found with Gorm for translating .gorm resources.
>>
>> Firstly, all string resources are not extracted.
>> "Gorm -> Document -> Translate -> Export Strings" makes .strings text
>> file, but some strings are omitted. For example of
>> "core/gui/Panels/English.lproj/GSPageLayout.gorm", the words such as
>> "Paper Orientation", "Portrait", "Landscape", "Dimension", "Scale" and
>> etc. are not exported. So these should be worked manually at Gorm
>> attribute window. Moreover, after saving translated work, "Export
>> Strings" generate string resources different from original one. Should
>> unexported strings be not translated? or Gorm cannot extract all strings
>> resources?
> 
> Gorm cannot extract all strings. This is a known bug.
> 
>>
>> Secondly, translated strings seem not to be preserved or not to be
>> displayed for some cases. Especially "Undo" and "Redo" of gui main menu
>> always shows untranslated text when excuting applications such as Gemas,
>> Ink which have undo and redo features. However, when opening .gorm
>> resource with Gorm, translated strings are conserved. I could not find
>> any stranges when looking after "Transalte" feature of Gorm source
>> itself. Is it related with NSUndoManager or GMArchiver?
> 
> This should be translated in GNUstep, not in each app. See for example:
> 
> base/Resources/Spanish.lproj/Localizable.strings
> 
> And
> 
> gui/Resources/Spanish.lproj/Localizable.strings
> 
>>
>> Thirdly, "cvtenc" tool seems not to work properly when converting UTF-8
>> strings to EscapeIn strings (/Uxxxx) while EscapeOut did well. GNUstep
>> resources strings should be UTF-8 native language code or ascii encoded.
>> Alternatively, native2ascii in JDK and uconv, iconv worked.
> 
> Don't know. I don't use it. But you can write the text normally and later 
> replace
> all the characters. Or add these characters to Gemas (file gemas/Resources/non
> EnglishCharacters.plist), so you can type these directly in the file.
> 
> Germán.
> 
>>
>> Regards,
>> Lee, Seong Gu
> 
> 

 Dear Germán Arias,

 Thank you for your advise. It solved the second problem.
 I have thought that core/base .strings resource only have string
encoding information and not reminded core/base non-English lproj.
Basically, all works are based on English resource because of knowing
about other languages little. From this instance, I'll deliberate on
others later.

 Regards,
 Lee, Seong Gu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]