[drupal-devel] Help system redesign

[Larry Garfield]

Wow this thread picked up steam today. :-)

To comment on all the replies to date so far, in no particular order:

1) I freely admit that my knowledge of PO files is virtually nill.  I suppose 
they could serve as the delivery file format, but how many developers know a 
PO editor?  I'd never even heard of one until about 2 weeks ago, but have 
been writing PHP for over 5 years.  Amazon insists that the Docs team will be 
writing all or nearly all of the help text anyway, but I still believe we 
should make it as easy as possible for non-Docs Team developers to write 
their own help text.  Remember, not all Drupal modules end up on drupal.org!  
I mention XML as an alternative because developers are far more likely to 
know XML than PO, I think.

2) I wasn't aware of the way in which translations are cached now.  If, as 
Khalid suggested, we could modify t() to handle lookups using a short key as 
well as the full English text, perhaps we could leverage the existing cache 
mechanism and let it do whatever it does?  That would be necessary to achieve 
the goal of getting big blocks o' text out of the .module file, as well as 
making the matching faster (see next).

3) The statement that very-long string PO lookups is slow is based on comments 
killes made in the aforementioned IRC discussion.  I will take his word on it 
unless someone can show otherwise. :-)

4) I firmly believe that any new help system should be designed in such a way 
as to encourage developers to provide context sensitive help.  Even if most 
of the context sensitive help *text* is written by the Docs and Translation 
teams, developers should be encouraged to include the hooks for it in the 
first place.  I suspect they'll want to provide at least an effort at text 
for it, if only to not ship code that reads "help goes here", so again some 
developer-friendly way of creating said text should be included.  Again, 
that's especially important for non-drupal.org modules that the Docs and 
Translation teams won't get a crack at either way.

On Sunday 25 September 2005 10:48 am, Gabor Hojtsy wrote:
> > I don't think there is any need to abandon PO as a format for
> > translators to work in. My main point was that if the text is going to
> > be moved to the database (as per the original suggestion) then an
> > online translation tool is an obvious next step (see below). We would
> > have to write import code to import the existing translations anyhow!
> >
> > As for XML, I just wanted to point out that a standard already exists,
> > and we should avoid making up our own (if we choose to support XML
> > import/export) unless there are good reasons. I don't have much
> > knowledge (or opinions) about about PO vs. XLIFF, but
> > http://mail.gnome.org/archives/gnome-i18n/2003-October/msg00032.html
> > seems to have some interesting points.
>
> Seems like you really don't know how things are done now. We already
> store translation strings in the database, in fact original English
> strings are stored a multitude of times along with translations. And
> then we already have an import/export facility for PO files. Note that
> once we started to support PO files (instead of using a web interface),
> the number of translations dramatically increased, very much passing our
> expectations.
>
> The fact that XLIFF might be better for someone then PO (explained on
> the link you posted up here), does not mean it is better for us. Someone
> who knows both need to do a comparision. Show us the needs in Drupal
> which XLIFF fulfills, and are not possible with PO files.
>
> >>What is not possible
> >>now? What is going to be better?
> >
> > I think you explained it yourself in your first paragraph. The
> > technical hurdles to learning translation tools and CVS are quite
> > high. While there is no problem with what we have now (other than
> > suggested in the Larry's original summary) there are always
> > non-technical people who want to contribute to open source projects,
> > and translation is an ideal opportunity to allow this. I feel that
> > having the option of using a web-based tool to allow this is good. If
> > I18N is important to Drupal (and it obviously widens the potential
> > market) then the volume of translation will have to increase
> > exponentially, and hence the more accessible we can make the
> > translation the better.
>
> I have seen the number of translations increasing once we started to
> provide a PO import/export interface, despite the CVS storage. Sure
> there were translations imported by Gerhard and others for the
> translators. Going on a completely different route does not solve
> current problems in itself, in fact it might be harder fo people to adapt.
>
> Goba

-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson