[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Separating in-source translations from */messages into own */srcmessages (or similar)
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2016-06-20 22:56:33
Message-ID: 2244365.CYtD9RzO63 () klux ! site
[Download RAW message or body]

Am Montag, 20. Juni 2016, 00:50:12 CEST schrieb Luigi Toscano:
> Albert Astals Cid ha scritto:
> > El divendres, 17 de juny de 2016, a les 12:30:00 CEST, Luigi Toscano va
> > 
> > escriure:
> >> On Friday 17 of June 2016 12:10:41 Friedrich W. H. Kossebau wrote:
> >>> Hi,
> >>> 
> >>> PROBLEM: garbage po and mo files in packages
> >>> 
> >>> currently many of the scripts used for creating release tarballs of KDE
> >>> software accidentally also add those po files to the tarballs whose
> >>> translations are already fed back directly into the sources by scripty
> >>> (with data files like appdata, desktop, json, or mimetype.xml). So
> >>> strings which will never be loaded from an external mo or qm catalog.
> >>> 
> >>> Those po files then also end up in the binary packages as mo files given
> >>> the generic handling of po files during builds. Do this to see how much
> >>> of those unneeded mo files you might have yourself on your system:
> >>> 
> >>> du -ch `find /usr/share/locale \
> >>> 
> >>>     -name "*appdata.mo" -o \
> >>>     -name "*mimetypes.mo" -o \
> >>>     -name "desktop_*.mo" -o \
> >>>     -name "json_*.mo"`
> >>> 
> >>> which for me reports in total 43M.
> >>> 
> >>> find ... | wc -l
> >>> 
> >>> is 186 here.
> >>> 
> >>> Problem is that many people are not aware of all the different data file
> >>> types which scripty cares for, and i18n in general is more seen as
> >>> "magic
> >>> which just works (mostly)" (well, shows the great work of the KDE i18n
> >>> team
> >>> 
> >>> :) ). And the number of such file types is rising now and then, just all
> >>> 
> >>> the different release scripts ("official" and home-grown) are not
> >>> keeping
> >>> up.
> >> 
> >> If someone writes a new release script, then the issues and requirements
> >> should be known.
> >> 
> >> I still fail to see why we need tons of release scripts. Let's fix the 3
> >> more used (sysadmin/release-tools.git for Frameworks and Applications,
> >> releaseme for Plasma and others, and create_tarball_kf5) and make sure
> >> that
> >> people are using them instead of reinventing the wheel.
> > 
> > How do you fix them though, i just had a look at what we do in the
> > Applications script and we just delete all files named desktop_*
> > 
> > Which i guess up to now is good enough but i would sayi it's impossible
> > for
> > Plasma to ever come up with a name for a catalog named
> > "desktop_controller" or something.
> > 
> > If we increase those catch all we'll eventually end up hitting one that
> > matches and have a hard time figuring out why it broke.
> > 
> > Maybe one of the ways to fix this is "fordidding" non autogenerated names
> > to have an underscore?
> 
> In another (now stuck) thread ("Renaming desktop_<module>_<program>.po
> file"), where we were discussing about the renaming json_foo.po and
> desktop_foo.po to foo.json.po and foo.desktop.po, a similar issue was
> raised.
> 
> A possible solution would be to use a specific suffix which we could quite
> sure is not going to be taken by any other user. I don't know, something
> like .__desktop.po and __json.po ? Then we could use that pattern to catch
> all of those special gettext file.

So packaging scripts could then use *.__*.po to filter out those po files. At 
least that would keep things more simple, instead of having to explicitly list 
all blacklisting filters. Or would you expect that to be done?

Where would that catching of patterns be done, besides packaging scripts?

Comparing the solution of such suffixes to a solution with a different 
directory IMHO the separate directory might still be simpler, once set up:

* packaging scripts tend to download all of the files in the respective svn 
folder. With suffixes solution only to delete some po files again then, 
suboptimal. Unless one writes more complicate code to first get the list of 
files, filter out all non-wanted po files and only then fetch the po files, 
but well, more complicate code to maintain.
* when visually scanning po files on svn (server or locally) to find some 
catalog, keeping all the scripty-only po files in the same folder makes it a 
little bit harder to quickly find the right file (much longer list).
keeping those files in separate dirs by their usage helps human look-up.
* suffixes with "__" inside make files create longer file names
 (and which look more ugly ;) ) 

So as user/consumer of the KDE i18n system, having a separate directory still 
seems simpler to me :)

Cheers
Friedrich
[prev in list] [next in list] [prev in thread] [next in thread]