Re: Localization good practices

Hello,

Seemingly, duplicating gorm files in *.lproj folders could not be a 
good practice.
So, if we should use only Localizable.strings, what should be the good 
expected practice.

Recently, we had some experiences with the need to duplicate gorm 
files (like within SimpleAgenda: see: 
https://github.com/poroussel/simpleagenda/issues/14) and in the same 
time that this choice could lead us in inconsistency (see French UI 
issue within AddressManager before svn revision 4073).

So I am sorry to ask again, but wee need to know approved practices to 
be efficient and helpful with Localization contribution.

Regards,
Patrick

On 2025-10-26 12:23:59 +0100 Patrick Cardona <[email protected]> 
wrote:

> Hello,
> 
> I am wondering about Localization good practices.
> 
> Documentation exists:
> - Chapter 18. Localization (by Yen-Ju Chen) at:
> https://www.nongnu.org/gstutorial/en/ch18.html
> - Chapter 7. Language support Localization (by Yen-Ju Chen and Dennis 
> Leeuw) 
> at:
> http://gnustep.made-it.com/GSPT/xml/Tutorial_en.html
> - Within Renaissance and I guess only for Apps made with it:
> https://deepwiki.com/gnustep/libs-renaissance/7.2-localization-tools
> 
> When we think about translation, we have three major things to deal 
> with:
> 1- UI of each app installed on the system
> 2- Services (menu items only?)
> 3- Help Resources.
> Do I forget something?
> 
> 1- About UI
> 
> What seems needed:
> a- Moving .gorm files to English.lproj;
> b- Generating Localizable.strings within Gorm;
> c- Adapting the path in GNUMakefile like this:
> 
> AppName_RESOURCE_FILES = \
> English.lproj/MainMenu.gorm
> 
> d- Copying English.loproj for example to French.lproj;
> e- cd in French.lproj and Translating each right fields in 
> Localizable.strings;
> f- Editing each French .gorm file with Gorm and importing the 
> translated 
> Localizable.strings;
> g- Maybe adapting the UI due to the length of some text tags.
> h- Adapting GNUMakefile to handle the new language implemented like 
> this:
> 
> AppName_RESOURCE_FILES = \
> English.lproj/MainMenu.gorm \
> French.lproj/MainMenu.gorm
> 
> (...)
> 
> AppName_LANGUAGES = English French
> AppName_LOCALIZED_RESOURCE_FILES = \
> Localizable.strings \
> MainMenu.gorm
> 
> i- Making and testing the UI in the language context targetted.
> Well, it is working (recently tested on StepSync)
> 
> - I am guessing about the steps "a, f-g", because, while studying the 
> GWorkspace organization, I noted there were only 
> 'Localizable.strings' in the 
> '*.lproj' folders. But without .gorm tranlated, I was not able to 
> achieve a 
> working L18N on my real example (StepSync).
> 
> 
> 2- Services
> 
> - How to translate services too?
> I don't know how to do this.
> 
> 3- About Help Resources
> 
> a- Moving AppName.help into English.lproj;
> b- Copying AppName.help into French.lproj;
> c- Tranlating the contents of AppName.help to French.
> d- Adapting the path in GNUMakefile like this:
> 
> AppName_RESOURCE_FILES = \
> English.lproj/MainMenu.gorm \
> French.lproj/MainMenu.gorm \
> English.lproj/AppName.help \
> French.lproj/AppName.help
> 
> (...)
> 
> AppName_LOCALIZED_RESOURCE_FILES = \
> Localizable.strings \
> MainMenu.gorm \
> AppName.help
> 
> e- Building and testing the menu command "Help...".
> 
> While the app is in French, the help shown was still in English.
> It seems that the relevant property in Info.plist is not concerned 
> yet by 
> L18N:
> 
> GSHelpContentsFile = "AppName.help";
> 
> - So I guess We must go into this in depth.
> 
> Regards,
> Patrick
> 

-- 
Patrick Cardona - Pi400 - GNU/Linux aarch64 (Debian 13.1)
Xorg (1:7.7+24) - libcairo2 (1.18.4-1+rpt1 arm64)
Window Maker (0.96.0) - GWorkspace (1.1.0 - 02 2025) - Theme: AGNOSTEP 
- MUA: GNUMail (1.4.0)