l10n-kde4/nl/docs/extragear-multimedia/amarok

[Matěj Laitl]

On 10. 8. 2012 Freek de Kruijf wrote:
> Op zaterdag 11 augustus 2012 00:27:42 schreef Matěj Laitl:
> > SVN commit 1310164 by laitl:
> > 
> > Re-add entities missing from KDE 4.6 to index.docbook
> > 
> > You perhaps update this using a script, so please fix the script or the
> > source it generates the index.docbook from.
> 
> Indeed. I just use the KDE tool scripts/update_xml to generate docbooks.
> Currently I use KDE 4.8, but a few month ago I used 4.6, but I copied the
> some of the kdelibs files from 4.8 to 4.6 in order to be able to generate
> the docbooks. Apart from you I received one more remark about this
> procedure.

I see. According to my chat with Albert Astals Cid (see attachement), it 
should be possible to tell update_xml to use different definitions than the 
installed ones.

So to summarise it:
 * when running update_xml for KDE SC 4.X, you should use definitions from 
kdelibs 4.X
 * when running update_xml for Amarok (and perhaps other extragear), you 
should tell it to use definitions from minimal KDE version Amarok depends on, 
can be found at [1].

[1] 
https://projects.kde.org/projects/extragear/multimedia/amarok/repository/revisions/master/entry/README

> I hope I can add these ENTITY definitions in the po file and generate a
> docbook which does not need any change by you.

Impossible according to Albert, see attached chat. Only solution is said to be 
expanding the entities manually. But don't bother with it for Amarok right 
now, already packaged 2.6.0 is most probably the last version to depend on KDE 
4.6.

Thanks for caring,
		Matěj
-------------- next part --------------
<tsdgeos>	yo
<tsdgeos>	laitl here?
<strohel>	tsdgeos: yep
<tsdgeos>	strohel: your commits to the docs files are hopeless
<tsdgeos>	they'll be overwritten on next update_xml run
<tsdgeos>	docs/ is "generated" content
<tsdgeos>	real stuff is in docmessages/
<strohel>	tsdgeos: Oh, I thought it was something like that.
<strohel>	tsdgeos: Thanks.
<tsdgeos>	sure
<strohel>	tsdgeos: Lemme look what the nl team has there.
<tsdgeos>	you can't "fix" docmessages to include those doctypes though
<tsdgeos>	doctypes -> entities
<strohel>	tsdgeos: So, how to fix that?
<tsdgeos>	so your only "possible" solution is replaceing the entities with the text
<tsdgeos>	or manually fixing the autogenerated docs each release
<strohel>	tsdgeos: Hmm, it seems that the nl team has to be educated what entities they can add
<tsdgeos>	well this is a hard education
<tsdgeos>	since where do they read that amarok can only use kdelibs 4.6 entities?
<strohel>	tsdgeos: Or, I know nothing about update_xml workflow, is it documented somewhere?
<tsdgeos>	or you expect them to know automagically?
<tsdgeos>	it's not what i'd call a workflow :D
<tsdgeos>	kdeunstable at xps:~/l10n-kde4:$ ./scripts/update_xml nl
<tsdgeos>	done
<tsdgeos>	:D
<strohel>	tsdgeos: No, I mentioned it in my previous commit CCed to l10n-nl-doc or how is their list called.
<tsdgeos>	sure
<tsdgeos>	in a commit you made how much ago?
<tsdgeos>	oh
<tsdgeos>	july
<tsdgeos>	did that get thorught?
<strohel>	tsdgeos: 2 weeks.
<strohel>	tsdgeos: Perhaps the mail was moderated, I'll check.
<tsdgeos>	ah you mailed their mailing list
<tsdgeos>	i thought it was the global i18n list
<strohel>	tsdgeos: http://lists.kde.org/?l=kde-i18n-nl&m=134412571503426&w=2
<tsdgeos>	yeah well
<strohel>	tsdgeos: They're somehow stubborn ;)
<tsdgeos>	we compile the docs nightly
<tsdgeos>	but obviously using current kdelibs
<tsdgeos>	so this is not the kind of error we find
<strohel>	tsdgeos: Can the script be told to use definitions from KDE 4.6?
<tsdgeos>	at the moment?
<tsdgeos>	no
<tsdgeos>	but if you do that
<tsdgeos>	it'll crap out on most of the kde SC stuff
<tsdgeos>	strohel: or you mean "update_xml"?
<strohel>	tsdgeos: Yes, or whatever generates nl/docs/extragear-multimedia/amarok/index.docbook
<tsdgeos>	update_xml basically uses the system files
<tsdgeos>	you can tweak it not to
<tsdgeos>	but you have to do it manually
<strohel>	tsdgeos: Is it called for all langs/projects in a batch, or every team calls it?
<tsdgeos>	it's team responsability
<tsdgeos>	it's a long term plan to do it automatically
<tsdgeos>	but it's a plan since years
<tsdgeos>	so don't count on it happening :D
<tsdgeos>	anyway this is not an unsolvable problem
<tsdgeos>	the nightly compilation could use a different kdelibs identity file
<tsdgeos>	if there's a file that defines the minimum requirent of non SC projects
<tsdgeos>	but this obviously means that file has to be kept up to data
<tsdgeos>	-a+e
<tsdgeos>	and means someone has to enhance the current scripts to do that
<tsdgeos>	which is "not trivial"
<tsdgeos>	and most certainly not on the top of my todo
<tsdgeos>	aaaaaaaaaaaaand sleep time
<tsdgeos>	getting late and need to get up early tomorrow