Eric Christensen wrote:
Totally agree. Using separate SRPMs is important to keep a
maintainable/scalable localization work-flow.
Cheers
That makes sense if you don't have a single maintainer of the SRPMS.
For the Fedora guides and articles (like the Release Notes) there is a
single maintainer of the SRPM.
This is the scenario we tested pre-RHEL 5 and having a gate keeper for
all languages proved to be one of the biggest problems. It simply does
not scale, the gate keeper gets swamped, updates get delayed, and the
system falls down.
We were dealing with less than half the languages Fedora supports and we
had a dedicated team of full timers on hand, so this is not a trivial
problem in the Fedora space.
So as translations are completed for the
Release Notes the maintainer adds them to the SPRM and does the update
in the packaging system.
This failed miserably when we tried this, how are you going to make it
work without changing the approach?
I'll concede that the release notes have a special place somewhere
between help text and stand alone docs, but because of this it is a poor
example of why you'd add this to a system dedicated to packaging stand
alone documentation.
This has the benefit of including a single package in the release that
Yelp will automagically select the proper language for the user.
Yelp is less than optimal for many reasons, such as: you just lost all
your branding, you are tied to a single desktop, you just increased the
payload by 50 times, you are ignoring section 508 compliance, etc.
This
is quite important as so the end user won't have to do anything but
select the document they are wanting to read. No fuss.
You can do that without yelp, without coupling to a particular desktop,
without losing the section 508 work we have done, without over riding
their chosen HTML viewer, etc.
I'm still waiting for an approach that isn't "we will do it the same way
you did it when it failed, but it will just work now (TM)."
Cheers, Jeff.
--
Jeff Fearn <[email protected]>
Software Engineer
Engineering Operations
Red Hat, Inc
Freedom ... courage ... Commitment ... ACCOUNTABILITY
_______________________________________________
publican-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/publican-list
Wiki: https://fedorahosted.org/publican
