[Scons-dev] SCons and intltool

[Pawel Tomulik]

W dniu 10.05.2014 15:59, Russel Winder pisze:

> On Fri, 2014-05-09 at 19:12 +0200, Pawel Tomulik wrote:

>> William,

>

> s/William/Russel/ – but you already covered that :-)

>

> […]

>> I wrote this gettext stuff some day, would be glad to help enhancing it

>> if there is a need. Looking for particular suggestions.

>>

>> The gettext code required in SConstruct/SConscrit usually limits to

>> two lines (Translate() and MOFiles()). The builders are described here:

>>

>> http://www.scons.org/doc/2.3.0/HTML/scons-user/a8588.html#b-Translate

>> http://www.scons.org/doc/2.3.0/HTML/scons-user/a8588.html#b-MOFiles

>>

>> providing few more examples.

>

> I will try things out more on a couple of projects to refine reactions

> and then either make proposals or back off. If there are proposals, what

> would be the workflow you'd want for collaborating on getting changes

> into SCons?


For the documentation I would suggest you (or the SCons team) to take an 
initiative. I could join a discussion and clarify whatever needs 
clarification during the refinement process and take a look at the final 
version if it agrees with the actual functionality. I propose this 
approach as English is not my first language and trying to enhance the 
documentation could yield opposite result :)


I believe that also the code needs some refactoring. This is separate 
task, which I could do by myself if the effort is reasonable.



>

> I think much of my problem is installation as much as creation of the

> translation files. Also support for translating desktop and schema files

> is missing, but I am not sure just now how to fit that in.


I've never used intltool, but from its description I understand that it 
"synchronizes" several sources of i18n messages (.xml.in, .desktop.in, 
etc.) with .po files (native to gettext). I think it's possible to add 
dedicated builder(s) for these suffixes to have at least one half of the 
intltool functionality supported. Don't know if the opposite direction 
can be implemented similarly.



>

> I think I am also getting irritated by the whole LINGUAS and POTFILE.in

> system Autoconf/Automake uses, which I suspect stems from them using m4

> processing for everything. Or is it better to manually specify things

> rather than try and deduce things from the filestore?

>


It's your choice - you may maintain file and language lists in these 
files or define them directly in SConscripts. As LINGUAS and POTFILE.in 
are supported, it's easier to be compliant with the old autoconf 
conventions. They're not obligatory in SCons gettext tools, however.

Existence of the LINGUAS file may be handy in two situations. First, 
with LINGUAS being in place it's easier for translator persons (which 
are not necessarily core developers) to find the list of languages 
supported by a project and eventually extend it. Second, when using 
variant builds you want to maintain .po files in source directory and 
commit them to your revision control system, whereas .mo files get 
created in the variant directory and cleaned up as any other output 
files. This usually leads to to separate SConscripts for the .po files 
(Translate() builder) and for other files (containing calls to MOFiles() 
builders). Both need to use same list of languages, so the LINGUAS is 
the common place, where this list resides.


Regards!

-- 
Paweł Tomulik