Al Dunsmuir <al.dunsmuir@xxxxxxxxxxxx> wrote on Tue, 12 Apr 2011 12:36:53 -0400: >I think these [file names such as "multi-user.target"] should be >viewed more as keywords, or reserved phrases >and not subject to translation. > >This is similar to a C program, where one has 3 cases: >- Comments and literal string can have nearly any value. >- Variable names are only restricted in the character set that can be > used. >- Language keywords must conform exactly. > >Having them be NLS-sensitive in a global subsystem in a multi-user >environment (where each user (or even process) is able to use a >different locale) seems to me a recipe for disaster. More like variable names than keywords. Keywords usually are from a small, fixed set. Sometimes they have a prescribed syntax (e.g. a distinctive character, such as the initial colon that denotes a Common Lisp keyword) that permits a vast number of keywords. Systemd targets are ordinary file names. They come from no enumerable set; there is no syntax that identifies a target name. English users are likely to find the standard target names descriptive. Other users will find them opaque, and the larger (more flexible) set of target names will be a challenge compared to single digits from 1-6. I have had experiences where I sought to understand C programs written by programmers not fluent in English. Despite a lot of C program experience and a good understanding of the C language, this was enormously more difficult than examination of similar programs written by English- speaking authors. This experience suggests the burden of systemd will be heavier for those not fluent in English. This is true for many aspects of Linux that derive from its English roots and development. I concur with your view it is unwise to undertake some sort of internationalization of systemd target names. I believe the flexibility that systemd provides is valuable, and I do not want to discard systemd. My point is systemd makes Fedora a little more difficult for a large number of people. A little times a large enough number can be a significant cost, especially if this scenario is repeated with other features. It seems possible that we can make a substantial number of sound decisions that "This feature is well worth the small breakage it costs." and fail to realize the aggregate cost may not be simply additive, but grow (for at least some users) beyond the total benefit these choices deliver. Fedora, with its leading-edge ambition, is a good vehicle to explore these issues, though I doubt we spend enough effort in retrospection. There have been many instances where Fedora replaced a facility with something new, a smaller number of cases where a feature was deemed "too broken to fix" and dropped, but few where a feature is successful but is abandoned because its cost is higher than expected. Maybe Red Hat Linux is the place for that, while Fedora chases the new, latest, and greatest. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
