As I wrote in bug 347, I do not consider this as a bug.
If you install the package tde-i18n-es, symlink {PREFIX}/share/doc/tde/HTML/es/krecipes/common will be correct. Similarly to other languages​​.

I believe that this can not be resolved. If the symlink in krecipes will "always" refer to "en", it would not be correct. At the same time it would not be proper to require for the installation of all tde-i18n-* packages. And it is also unrealistic to symlink controlled depending on whether the language pack is present at the build time.

Therefore, I see no way it could be solved differently than it is now.

Other packages do not have this problem. :)

In my build scripts I have do the following for all affected packages:

# Repair sym links. Problem addressed in Trinity bug report 1611.
# Need test only one link --- if one is broken then all are broken.
if [ "`readlink $PKG${PREFIX}/share/doc/tde/HTML/da/krecipes/common`" = "${PREFIX}/share/doc/tde/HTML/da/common" ]; then
  (cd $PKG${PREFIX}/share/doc/tde/HTML/da/krecipes; rm -fr common; ln -sf ${PREFIX}/share/doc/tde/HTML/en/common common)
  (cd $PKG${PREFIX}/share/doc/tde/HTML/es/krecipes; rm -fr common; ln -sf ${PREFIX}/share/doc/tde/HTML/en/common common)
  (cd $PKG${PREFIX}/share/doc/tde/HTML/et/krecipes; rm -fr common; ln -sf ${PREFIX}/share/doc/tde/HTML/en/common common)
  (cd $PKG${PREFIX}/share/doc/tde/HTML/pt/krecipes; rm -fr common; ln -sf ${PREFIX}/share/doc/tde/HTML/en/common common)
  (cd $PKG${PREFIX}/share/doc/tde/HTML/sv/krecipes; rm -fr common; ln -sf ${PREFIX}/share/doc/tde/HTML/en/common common)
fi

(Odpověď na komentář #2)
> Other packages do not have this problem. :)
> 
> In my build scripts I have do the following for all affected packages:
> 
> # Repair sym links. Problem addressed in Trinity bug report 1611.
> # Need test only one link --- if one is broken then all are broken.
> if [ "`readlink $PKG${PREFIX}/share/doc/tde/HTML/da/krecipes/common`" =
> "${PREFIX}/share/doc/tde/HTML/da/common" ]; then
>   (cd $PKG${PREFIX}/share/doc/tde/HTML/da/krecipes; rm -fr common; ln -sf
> ${PREFIX}/share/doc/tde/HTML/en/common common)
>   (cd $PKG${PREFIX}/share/doc/tde/HTML/es/krecipes; rm -fr common; ln -sf
> ${PREFIX}/share/doc/tde/HTML/en/common common)
>   (cd $PKG${PREFIX}/share/doc/tde/HTML/et/krecipes; rm -fr common; ln -sf
> ${PREFIX}/share/doc/tde/HTML/en/common common)
>   (cd $PKG${PREFIX}/share/doc/tde/HTML/pt/krecipes; rm -fr common; ln -sf
> ${PREFIX}/share/doc/tde/HTML/en/common common)
>   (cd $PKG${PREFIX}/share/doc/tde/HTML/sv/krecipes; rm -fr common; ln -sf
> ${PREFIX}/share/doc/tde/HTML/en/common common)
> fi

And this is exactly the solution that is wrong.

Language packs tde-i18n-* may contain language-specific 'common' files. Applications should properly refer to a language-specific 'common' rather than the common 'en'.

Your solution will cause that the 'common' parts can not be dependent on the language => cannot be translated => cause bug.

> And this is exactly the solution that is wrong.
The solution works for me because I don't use any i18n files. :-)

Yet that begs the question: what _is_ a proper solution? I refuse to believe these broken sym link reports are not resolvable. :-)

(Odpověď na komentář #4)
> > And this is exactly the solution that is wrong.
> The solution works for me because I don't use any i18n files. :-)
> 
> Yet that begs the question: what _is_ a proper solution? I refuse to believe
> these broken sym link reports are not resolvable. :-)

I do not know what would be a useful solution.

At the time of building the application cannot know what language packs tde-i18n user will have installed => what links may be valid. At this moment it is not possible to resolve references. This is not the right way.

Similarly, it is nonsense to solve links at installation package. For packaging systems as deb and rpm it would break packages checksums. Moreover, it would not only have to deal with all applications, but also all the tde-i18n packages. This is clearly an incorrect solution.

Therefore, for me, the best solution seems to be to create symlinks, so they expect that user install desired tde-i18n packages. Without tde-i18n packages symlinks will be invalid, after installation tde-i18n package symlinks will works correctly. It seems likely that, for example, Spanish users will have installed package tde-i18n-es and the symlinks for Spanish will be fine.

Perhaps we're discussing two different issues. :) I'm discussing --- and filing bug reports --- against the main package, not any extra tde-i18n packages.

When I install the krecipes package, I'll find the aforementioned broken sym links. The sym links are pointing to the wrong directory. All 'common' files are installed in the 'en' directory. Those common files are not necessarily English files, most are files such as PNG files. So the doc files for the supported languages of the main package need to point to the common directory.

Run the following command:

find /opt/trinity -type l -print | perl -nle '-e || print'

You'll find broken sym links.

The broken sym links mean those supported languages in each affected package will not correctly display PNG images, etc., in the help documentation.

I mentioned in comment 2 how I fix these broken sym links in my build scripts. This is a sledge hammer approach.

All I am doing in my build scripts is correcting the broken sym links for the doc files in the main package. That has nothing to do with tde-i18n packages that might exist. If the main package has po files and i18n support, then the sym links should point to the correct 'common' directory.

Here is what the broken krecipes sym links look like untouched:

/opt/trinity/share/doc/tde/HTML/da/krecipes/common -> /opt/trinity/share/doc/tde/HTML/da/common
/opt/trinity/share/doc/tde/HTML/es/krecipes/common -> /opt/trinity/share/doc/tde/HTML/es/common
/opt/trinity/share/doc/tde/HTML/et/krecipes/common -> /opt/trinity/share/doc/tde/HTML/et/common
/opt/trinity/share/doc/tde/HTML/pt/krecipes/common -> /opt/trinity/share/doc/tde/HTML/pt/common
/opt/trinity/share/doc/tde/HTML/sv/krecipes/common -> /opt/trinity/share/doc/tde/HTML/sv/common

All of these sym links should point to /opt/trinity/share/doc/tde/HTML/en/common. Like this:

/opt/trinity/share/doc/tde/HTML/da/krecipes/common -> /opt/trinity/share/doc/tde/HTML/en/common
/opt/trinity/share/doc/tde/HTML/es/krecipes/common -> /opt/trinity/share/doc/tde/HTML/en/common
/opt/trinity/share/doc/tde/HTML/et/krecipes/common -> /opt/trinity/share/doc/tde/HTML/en/common
/opt/trinity/share/doc/tde/HTML/pt/krecipes/common -> /opt/trinity/share/doc/tde/HTML/en/common
/opt/trinity/share/doc/tde/HTML/sv/krecipes/common -> /opt/trinity/share/doc/tde/HTML/en/common


I'm sure the fix is simple, but I have no experience with makefiles.

Run the above find command and you'll find the broken sym links. Fix the broken sym links as I shared in comment 2. Then again run the find command and notice the sym links are no longer broken. :)

I can only repeat:

Although the proposed solution simple fix unresolved symlinks, but make from this "wrong" symlinks, because it is incorrect to pointing always to 'en', instead of to language specific folder. This is a bad solution.

Folder 'common' does not contain only images but also files that are to be localized. Poiting all languages ​​to 'en' disallow to translate 'common' part. It *is* wrong.

Currently there are too many broken sym links. They need to be fixed. To where the sym links point is not as important to me that they get fixed and are not broken. What might be the "correct" solution is a different discussion.

Hey, I agree with Slavek !
Every language has its own "common" directory, provided by the corresponding "tde-i18n" package.
You must NOT make a localized package use the english "common" folder, because it will likely break some translations !

I prefer having dead symlink with working translations, rather than valid symlink with broken translations !

Okay, okay! Just fix the problem! :-)

And living with broken sym links is not a solution! :-)

Look at the problem from a different point of view:

Individual languages must refer to 'common' folder under the appropriate language. This is the current state - symlinks *are* correct.

To be valid symlink to 'en', must be installed package tdelibs - on Debian and Ubuntu more precisely tdelibs-data. In order to be valid symlinks for other languages ​​must be installed packages tde-i18n.

Therefore, the bug is not in the packages krecipes, amarok, and others, but in that you have not installed packages tde-i18n. Install the necessary packages tde-i18n and you have corrected this problem - all 'common' symlinks will be valid. :)

>I prefer having dead symlink with working translations, rather than valid >symlink with broken translations !(In reply to Francois Andriot from comment #9)

Even though I don't use any tde-i18n package, I agree with Slavek and Francois.
If a user doesn't have any tde-i18n package installed, then it is very unlikely he will ever encounter the broken symlinks.
And if the proper i18n package is installed, the symlinks will work correctly.

The solution proposed by Darrell is wrong: it doesn't fix any real user problem (those broken links do no harm at all) and instead introduces problems for users that use tde-i18n packages (links will refer to wrong localization folder).

I propose we close this bug and all the similar ones as WONTFIX.

Closed as WONTFIX. A comment explaining the reason for the broken symlinks will be added to the release notes.