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

List:       kde-i18n-doc
Subject:    Re: Renaming desktop_<module>_<program>.po file
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2018-04-13 18:45:26
Message-ID: 5424915.TONETlIzRv () xps
[Download RAW message or body]

El divendres, 13 d'abril de 2018, a les 0:13:52 CEST, Luigi Toscano va 
escriure:
> Albert Astals Cid ha scritto:
> > El dilluns, 20 de juny de 2016, a les 23:47:43 CEST, Luigi Toscano va
> > 
> > escriure:
> >> Burkhard Lück ha scritto:
> >>> Am Dienstag, 12. April 2016, 16:22:03 CEST schrieb Luigi Toscano:
> >>>> Chusslove Illich ha scritto:
> >>>>>> [: Luigi Toscano :]
> >>>>>> So the question is: are there any major blocker for implementing the
> >>>>>> change from the current pattern to <program>.desktop.po?
> >>>>> 
> >>>>> I have just one little note: there already exist one catalog named
> >>>>> plasma_shell_org.kde.plasma.desktop.po, that is not a desktop PO. Not
> >>>>> sure
> >>>>> if that will cause some confusion somewhere. And renaming this one
> >>>>> catalog
> >>>>> to something else may also be not nice, because it follows the
> >>>>> reverse-
> >>>>> domain naming pattern.
> >>> 
> >>> All catalogs in trunk kf5 with naming scheme "*desktop.po" but no
> >>> desktop
> >>> file:
> >>> 
> >>> docmessages: kcontrol_desktop.po + plasma-desktop.po
> >>> 
> >>> gui messages:
> >>> kcm_kwindesktop.po, plasma_applet_org.kde.plasma.showdesktop.po,
> >>> plasma_runner_plasma-desktop.po,  plasma_shell_org.kde.plasma.desktop.po
> >>> 
> >>>>> (In the summit I didn't want to think about this, so as a precaution I
> >>>>> set
> >>>>> it to be renamed to plasma_shell_org.kde.plasma__desktop.po.)
> >>>> 
> >>>> Good point: this won't probably happen too much, but maybe we can
> >>>> define
> >>>> a
> >>>> custom prefix which is not going to conflict with normal use cases?
> >>>> Maybe
> >>>> <program>._desktop.po
> >>>> <program>._json.po
> >>>> ?
> >>> 
> >>> What these catalogs (desktop, json, appdata, mimetypes) have in common
> >>> is
> >>> that they are generated by scripty for internal use only.
> >>> 
> >>> We already have the suffix "_qt.po" to distinguish between Gettext and
> >>> Qt
> >>> translation system.
> >>> 
> >>> Similar we could use a suffix like e.g. "_scripty.po" for the catalogs
> >>> generated by scripty for internal usage.
> >>> 
> >>> *_desktop_scripty.po
> >>> *_json_scripty.po
> >>> *_mimetypes_scripty.po
> >>> *_appdata_scripty.po
> >>> or a reverse naming scheme
> >> 
> >> Using scripty as marker is a possible solution. I personally don't like
> >> too
> >> much to use "scripty" explicitly but I wouldn't oppose the solution.
> >> I'd like to propose to break the _<something>_scripty.po part with a dot
> >> instead of a simply _, but it would be just for clarity.
> > 
> > Anything that is unambiguous enough that it won't be part of a "regular"
> > catalog is good enough
> 
> Resurrecting this 2-years old thread because I think that the only blocker
> to the rename is now fixed.
> 
> Any final opinion about the pattern?
> 
> Burkhard's proposal was:
> *_desktop_scripty.po
> *_json_scripty.po
> *_mimetypes_scripty.po
> *_appdata_scripty.po
> 
> I suspect that a dot is needed before the first _:
> file._desktop_scripty.po
> 
> As I mentioned, I'd prefer to remove scripty and use a pattern like
> foo._<type>_.po or foo.__<type>__.po.
> 
> What do you think?

I really don't care :D

Cheers,
  Albert

> 
> Ciao




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