> >(2) I haven't actually seen Autrijus =encoding proposal :-) ... but how
> >about the possibility of indicating the languages, too? =language
> >ISO639codehere.
> Just for the sake of metadata, you mean? What uses do you have in mind for
> this?
Mixing several languages in the same document but marking the appropriate sections with their languages so that a "subdocument" containing only a subset of the languages can be extracted.
I have dim but definite memories that there are real problems with extracting things like this. I think that some problems go away if the extraction is /never/ on by default. That is, things are okay if you have a document where everything is in Italian and in English, and clearly says "If you want to strip out the Italian, format this with --leaveonlylang=it. For the English-only version, format this with --leaveonlylang=en."
However, if you were to automatically infer a leaveonlylang value from the user's locale, then things get nasty in such cases as documents where there there is only partial translation -- like where it's mostly Italian, but there's an English abstract.
Hm.
Now that I think about this more, I /think/ this basically introduces a sort of macro-processing #ifdef-like layer for Pod, which I'm extremely hesitant about. It could easily turn into a real nightmare for programmers and pod-authors alike. And that's the last thing Pod needs at this point!
Might it be better to have "=for lang somelangcode" as a flag that means that stuff is in this Somelanguage? (up until the next "=for lang someothercode", or "=for lang *" for stuff applicable to all languages")
And then have some non-perldoc program be in charge of doing the inclusion/exclusion of applicable sections, whose output could be fed to perldoc or whatever?
If this feature really is as dubious as I worry it might be, then I'd be a whole lot happier if we could just call it "experimental", segregate it in an external program, and not rush to actually bless it with support in Pod::Simple and Pod::Perldoc. Having it be an external program for the forseeable future would at least make it clear to people that this preprocessing step is not part of Pod itself.
Thoughts? Suggestions?
(As I return to just fretting over the implementation of =encoding ...)
-- Sean M. Burke http://search.cpan.org/~sburke/
