https://bugs.kde.org/show_bug.cgi?id=497653
--- Comment #9 from Karl Ove Hufthammer <[email protected]> --- It’s very tempting to make this feature ultra-flexible to cover all cases, with nested sets of groups of TMs, where one can enable/disable the various sets per project (or even per meta-project). But in my experience, such flexibility makes the UI too difficult to use and understand, and most people would just ignore it. So I think we should aim for a solution that covers the most important use cases and that which still is flexible enough for *most* users and use-cases (remembering that everything will be an improvement over the current implementation). Here are a couple of things I think is important: 1. For a given project, it must be possible to explicitly choose which TMs to use (including ‘none’). 2. It should be possible to select a standard/default set of TMs (and to reuse this in various projects). Based on this, I think a sensible implementation would be: A global setting which lists all TMs and where one can check (enable/disable) the TMs that should be the ‘default’/global TMs. When opening a file without having a project open, these TMs would automatically be used. For each project, have a similar list of TMs in the project options, but with an additional option/pseudo-TM named ‘Use the global translation memories’ (placed at the top of the list). One can choose to enable/disable this and/or any of the other TMs. These are project-specific settings. For *new* projects, only the ‘global pseudo-TM’ will be enabled by default. With this implementation, one can choose a specific set of TMs for each project. But can also choose to just use the global TM set. For some people (like me), the global TM set would include *all* or most of the TMs. For some people, it would include only a single TM (perhaps only a curated set of translations likely to be used across various projects). And for a single project, it will be easy to choose to use 1) only the global TM(s), 2) the global TM(s) + one or more project-specific TMs (e.g. KDE TMs for a KDE project, or GNOME TMs for a GNOME project), 3) only project-specific TMs (for one-off projects). >From a user’s perspective, I think this will be quick and easy to set up. Except for the global default, it won’t have the flexibility of having *sets* of TMs (e.g., a meta-TM called ‘Games’, which could include TMs for several game translation projects, for easy use). But I think such a feature wouldn’t be used often enough that it’s worth complicating the UI and the user’s mental model of how the TM stuff works. When you create a new TM, this will have no effect on the global TM list or on the project-specific lists (i.e., it will *appear* on the lists, but unchecked) . If you want to include it, you’ll have to explicitly enable it. This is the simplest solution and I think it would be OK for the first implementation. (Later, it might be OK to add a ‘Use all available translation memories’ option the global setting.) -- You are receiving this mail because: You are watching all bug changes.
