Ben Walton

User gains

1. No potential for out-of-step releases between CSWcommon and $package_supplying LC_TIME files (links or real). This improves the user experience by eliminating a source of error and confusion (which package is wrong, why is it broken, etc).
2. Consistency in delivery of .mo files for all of LC_{TIME,MESSAGES,NUMERIC,etc}.
3. Fewer changes to CSWcommon, which should be a stable¹ package.
4. Provides a standard file/directory layout suitable for local (non-CSW) software installation without understanding our 'unique' approach to things. This requires less time (researching collision issues) and thus effort on the part of users who may build things against our application stack.
5. Consistency with Linux distributions.

Philip Brown

User gains

There is no current gain to user experience.

Maintainer gains

1. No requirement to update CSWcommon[1] any time new locales are added to any package shipping LC_TIME files. This reduces time for maintainers of any package delivering LC_TIME files as there is no co-ordination required with CSWcommon. In turn, this reduces the packaging effort.
2. Packages will deliver files in a manner consistent with the recommendations of the gettext maintainer²
3. No extra packaging steps required to strip out the LC_TIME directories.

Maintainer gains

Gain to current maintainer experience, is that exactly one existing package would avoid to have a one-line change to it.

Ben Walton

User gains

There is no gain in user experience.

Philip Brown

User gains

To have the LC_TIME functionality fully working for applications that support it. Deploying LC_TIME functionality can be complicated, and is poorly documented. Even an application that explicitly supports it in its code, can miss deploying the LC_ files properly. If so, then LC_TIME will not work properly even though the code supports it.
LC_TIME functionality is important enough that an international standards committee decided to split it out in LC_ in the first place. Plus redhat recognized it and declared missing out on it, as a bug of severity=medium³.
It was this bug that caused fileutils itself to be patched, as noted back in pre-coreutils days:

2002-11-09  Jim Meyering  <jim@meyering.net>

      * Makevars (EXTRA_LOCALE_CATEGORIES): Add LC_TIME.
      Patch by Tim Waugh for Red Hat bug #73669.

Maintainer gains

There is no gain in maintainer experience.

Maintainer gains

To properly enable LC_TIME functionality to those programs that support it at the code level, without the maintainer having to do a single extra piece of work.

Ben Walton

There is no cost to users in this case. The software works as expected (barring other issues/bugs).
There should be no cost to other maintainers either, as they have no need to handle the case where their app delivers files to $locale/LC_TIME/domain.mo. (The other solution would see special handling for this required (time/effort) to remove those LC_TIME directories.)

Philip Brown

Cost to users: There may be some existing packages that get LC_TIME functionality from the global symlinks now, that may lose it.
The other solution blocks the approach of csw-global LC_TIME directory symlinks, which means that any programs that are not fully LC_TIME aware, will not get deployed properly, and so users may miss out on LC_TIME functionality that they could otherwise use.
Unless [here's the "cost to maintainers" bit] every maintainer of every package, did an analysis of LC_TIME functionality, and somehow ensured that package-individual symlinks for LC_TIME got created when needed. Something that I do not think is feasible, due to lack of widespread technical knowlege of this issue. It would be nice if this analysis were automatable. But if it is, then why doesnt GNU autoconf itself automate it?

Ben Walton

There is potential for several issues with the alternate solution:

1. Locally built software (potentially) needs to be aware of our special handling of this issue.
2. If a new package delivers files in LC_TIME and isn't aware of this handling, we can have either the current situation of symlinks being overwritten with invalid symlinks or (in the case where a new locale is being delivered) an inconsistency in handling between directory symlinks and 'normal' files/symlinks.
3. The release of any package shipping a new locale and LC_TIME files needs to coordinate this effort with CSWcommon releases.

This leads to possible confusion at the user side and a lack of 'polish' in the perception area. It is different from the way Linux distributions ship these files. Additionally, it imposes a double-burden on maintainer time. The maintainer of any package delivering LC_TIME/$domain.mo files needs to be aware of our special handling of this.
MORE IMPORTANTLY, if a package (see SUNWfros as a non-CSW example) wants to ship .mo files that are independent of the content in LC_MESSAGES/, they are not able to do so. This not only goes against the gettext standard, but also against the publicly stated recommendations of the gettext maintainer.

Philip Brown

Minimal to none.
If standard symlinks in 'common' are uniformly implemented, most maintainers and users need do nothing. At the moment, there is exactly ONE package that requires a change from defaults for, and the change is only to filter out the LC_TIME entries from the prototype file (or alternatively, to patch out the "EXTRA_LOCALE_CATEGORIES" line in Makefile.vars)
GAR could be made to take either approach, which would make the individual maintainer cost zero.
Very worst case: If some day, after 6 years now, a program appears that actually delivers a separate file in LC_TIME; that file can simply be appended to the file in LC_MESSAGES. Functionality will be unchanged from a users' perspective, with the LC_TIME symlink. But, this separate LC_TIME file will never get created with an autoconf program. (which is why we never see one). The GNU locale instructions step you through automatic generation of a single locale-related file, which then gets deployed to LC_MESSAGES only⁴.
It is because of this,that the EXTRA_LOCALE_CATEGORIES functionality to autoconf was created. Its explicit purpose is to add *symlinks*, not files, to the other locale dirs, aka "categories", *IF* the software author remembers to add it in manually. Unlike most other autoconf features, the need to use this feature is not auto-detected by autoconf, I believe.