James Tyrer posted on Tue, 23 Apr 2013 11:16:55 -0700 as excerpted: > No, hard coding as in being in the code and not something that changes > with the outside world. It is a string literal in the i18n function. > The point here is that it does not conform to the directory name for > $XDG_DOWNLOAD_DIR on the users system for a default and the user can not > change it. I still call that hard coded even if it would be changed for > translation.
Reading the thread, it occurs to me that one solution might be to create a custom "l10n", that's the same as the user's normal l10n by default, with only the desired customizations. That sounds like something I might do here, if the existing situation bothered me enough and I was already using some non-default l10n. But of course since I'm native en-US, in most cases I don't bother with l10n at all and don't even install the packages. So for me, it'd probably be easier to simply find and patch the default pre-l10n string directly in the package code... And one of the benefits of running gentoo is that once I find such a bit of code and deduce the change to it needed, I can create a patch and drop it in the appropriate location, and all updates get that patch from then on, as long as it applies (and when it no longer applies I get an error when that package tries to update, which I can investigate and redo the patch or choose another alternative as necessary). And I do have a number of such patches so located in the appropriate location, thus being routinely and automatically applied as I update. Tho they're normally for other things. For instance, gwenview's default zoom-step was changed a number of versions ago to 100%. But I preferred the earlier, much smaller increment, so I found the location where that was set and devised a patch that changed a "1." value to "0.05", and now have 5% increments once again. =:^) AFAIK, the last time I actually had to do that with a name string or similar, was with (the non-kde) pan. One release version was named (IIRC) "Der Geraet", which (with appropriate umlauts or whatever) I understand is German for "The Tool". All fine, except that pan passes its version name as a message header, and RFC-standard internet-message headers aren't supposed to contain anything but 7-bit-ASCII (quite another problem, actually, requiring all sorts of encoding solutions and triggering various chicken and egg issues due to needing to know the encoding without having necessarily parsed the header that would declare said encoding, something that UTF-8 is gradually helping to solve, but...). Anyway, I was and am running live-git pan, and with the commit changing the name to something now including non-ascii, I suddenly found my posts to various lists rejected. But since I was running live-git, there were only a couple commits it could be, and the rejection-bounce from one of the lists mentioned it was a non-ASCII header issue, so that eliminated all but the one commit, making it easy to see what went wrong and to devise a patch without the umlauts or whatever non-ascii chars, which I then applied locally while reporting the issue upstream. The first attempt at a fix simply attempted to encode the non-ascii, but that didn't work as the thing was decoded elsewhere in the code with the same non-ascii header as a result. Of course that made my patch not apply. But there weren't that many other commits going in at the time, so while I continued updating to see when a further fix was applied, I simply didn't actually build a new version for a few days. The second attempt at a fix basically applied the same patch I did, using the standard ascii text without umlauts, etc, at which case I was able to discard my patch and update as normal once again. So that was only a few days' problem, but had I not been running live-git pan, it probably would have made it into a release, and been a much worse problem as it would have applied to many more people over a much longer period (probably a six-month distro update cycle at least, assuming the distro maintainer didn't catch it, as they probably wouldn't have given the nature of the problem). But I /was/ running live-git, and the ability to apply patches like that allowed me to verify the problem before reporting the bug, as well as deal with it for the few days before a proper fix. Which demonstrates the point, that this sort of problem is much rarer for FLOSS projects, since someone somewhere generally catches it and reports a bug back to the much more accessible authors, who generally fix it, and if not, the distros generally catch it in a cycle or two, so the problem goes away for most users, instead of persisting as it would with proprietaryware thru a much longer release cycle. But in this case, apparently the "bug" has continued for some time, going to my point about kget being rather obscure for a FLOSS project, these days, so because it's not used much and some users wouldn't worry about such a trivial thing as a name or even <shudder> /like/ such MS-esque names, few people are reporting the bug, and those that are haven't caught the attention of the authors, so it remains unfixed. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
