discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Problem with Gorm Translate


From: Germán Arias
Subject: Re: Problem with Gorm Translate
Date: Thu, 24 Oct 2013 19:30:20 -0600
User-agent: GNUMail (Version 1.2.0)

On 2013-10-24 18:56:55 -0600 "Lee, Seong-Gu" <sgleehd@gmail.com> wrote:

> 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
> 
> 

This is because the file Localizable.string (english) has not been
updated. But the corresponding file in GUI is updated.

Germán.




reply via email to

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