Nick Phillips wrote: > Not when you take the full argument into account; textual data in packages > is just that --- data. It really is logically separate from the code, as > gettext helps show. You may notice that debconf does a lot more sepration of text and code than most programs. However, the text and code are still very tightly bound. If they get out of sync, the admin may see confusing or even dangerous things. > * It's a potential PITA for maintainers; they should be able to choose whether > to be involved in translation or not (clearly some feel strongly each way). No, maintainer should be able to chooe between using a very simple and well-nigh utomated system for manging the trnslations in their package, or taking a more active hand. Any maintainer who does not realize that any translation has the potential to break his package, and is not willing to take responsibiliy for it just like any other bug in his package, needs to reexamine his commitmnt to the project. Any maintiner who *does* realize this will not want third parties messing with it out side of his control. He'll want to at least eyeball all new translations before they go in, even if he doesn't know the language. He'll want to be able to remove a translation or fix a typo when he gets an urgent bug report from a user. > * We should not be requiring all systems (or even archives) to install 20 or > more (just a guess) times the amount of textual data that most will need. For > some packages this will be significant, for others not. This is the only real concern (or more exactly in the long term, having to download all those translations and then probably throw them away as your system is not configured to install them). > * It fits the standard UNIX way of doing things (avoiding monoliths). Monoliths? So you think that we should have one packge for every file on the system? -- see shy jo
Attachment:
pgpheWVOQ_t15.pgp
Description: PGP signature