seems to me it happens for the languages which don't have the stuff on it's own
but get the en-US one during packing instead. (de, fr etc. do work correctly)

.

ingo, do you have a clue whats up here?

@mechtilde: Did you use DEFAULT_TO_ENGLISH_FOR_PACKING for the creation of the
installation set? This is only valid for testing installation sets, but NOT for
releases. 
If language dependent files from a zip file are installed into a directory, that
is not language dependent, this files have to be renamed to avoid conflicts.
Maybe someone wants to install an English language pack later. The renaming
process adds the language, for which the file is not available, in your case
"as". But this is not guaranteed to work, so that for official releases, the
correct files have to be available before packaging starts. In your case you
have to create a "palettes_as.zip" in which you include a "modern_as.sog".
Otherwise you cannot release installation sets in language "as".
In the log file of your packaging process you will find something like:

RENAME_TO_LANGUAGE: Using <newfilename> instead of <originalname> 

I get the builds from here:
http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/localization/OOO321l10n/

By the way: If you suggest, that "modern_en-US.sog" should be renamed to
"modern_as.sog", then this might solve this problem, but it is not guaranteed
for all processes. There can be other directories, in which an English
"Arrow.jpg" is located next to a German "Pfeil.jpg". In this case, the packaging
process can only rename "Arrow.jpg" into the incorrect "Arrow_as.jpg". 
Additionally you might get license problems, if you include only English license
files. Some countries might require localized license files.
The simple answer is therefore: DEFAULT_TO_ENGLISH_FOR_PACKING is good for
testing, but not for releases!  

@mechtilde: I see, so this is not your build problem. The installation sets are
broken because of misused tooling.

@ihi: Please do not use DEFAULT_TO_ENGLISH_FOR_PACKING for installation sets,
that you want to release.

> The simple answer is therefore: DEFAULT_TO_ENGLISH_FOR_PACKING is good for
> testing, but not for releases!  

DEFAULT_TO_ENGLISH_FOR_PACKING is used by anyone (even inside Sun, Mechtilde
didn't build it herself) for builds. And at least me don't talk about
installsets but language packs. (That's where I saw it in Debian,
see e.g.  http://packages.debian.org/squeeze/all/openoffice.org-l10n-as/filelist)

You don't seriously suggest we don't ship UI translation of e.g. as at all when
we don't have those zips for as just because the packaging of those sucks?

If there are missing files in a specific language, you cannot create any product
for this specific language. It does not matter, if you mean OOo or language
packs or whatever. How should the packaging process create the missing files
automatically? This might work in some cases but cannot work reliable.

And what means: DEFAULT_TO_ENGLISH_FOR_PACKING is used by anyone? There has
never been such an announcement. It is only used very often, because it is so
comfortable, to shift the problem of missing files to the packaging process. But
this cannot be a solution. This can only be a fake, that is valid for testing,
but not for releases.

> If there are missing files in a specific language, you cannot create any product
> for this specific language. It does not matter, if you mean OOo or language
> packs or whatever.

I disagree. The UI works etc and that's what's the main purpose of it. Even
templates are there.

> How should the packaging process create the missing files
> automatically? This might work in some cases but cannot work reliable.

Maybe. Not my issue, though.

> And what means: DEFAULT_TO_ENGLISH_FOR_PACKING is used by anyone? There has
> never been such an announcement.

It does not matter whether there was one. As we see everyone as to now
uses it (and when it first came in everyone explicitely was advised doing so)
configure/set_soenv.in sets it as default, too (prompted by an issue, I forgot
its number)

> This can only be a fake, that is valid for testing, but not for releases.

So effectively remove most of the languages we have in OOo. I don't think that's
what you want (or do you?) either.

(At least me probably will continue to use DEFAULT_TO_ENGLISH_FOR_PACKING, I
will not jeopardize speakers which can get a working language pack just because
there is this localized arrows not there for that specific language and using
the english one is ok - I'll just do a mv, though to fix the name)

That can't be the right way

If *I* download a build for testing which is either an CWS build or an DEV build
I expect that it is built like the release build. 

For the CWS build I don't want only to test the functionality of the CWs buat
also the functionality of the whole build.

So it doesn't make sense to use different parameters especially without any
declarations.

And again for understand I never build a version myself because IMHO it is not
effective that QA look at own builds.

I find the idea of localizing the png names such a brilliant one. It must be
great to be able to write سَهْم.png instead of Arrow_ar.png :) or तीर.png instead
of Arrow_hi.png :)

is: Issue 45118

13:13 < _rene_> paveljanik: I think you want to comment on issue 110901 :-)
13:14 <@IZBot> l10n DEFECT NEW P1 [CWS OOO321L10n] Wrong File Names of Located
Files http://qa.openoffice.org/issues/show_bug.cgi?id=110901
13:19 <@paveljanik> _rene_: no, I don't want to comment the issue. is is plain
wrong there.
13:19 <@paveljanik> is^2 ;-)
13:19 <@paveljanik> of course everyong building for more languages has that
variable set up 8)
13:20 < _rene_> of course he is
13:20 -!- Carutsu [~carloslic@pd95b933f.dip0.t-ipconnect.de] has quit [Ping
timeout: 252 seconds]
13:20 <@paveljanik> 2004-10-16  Pavel Jan?k  <Pavel@Janik.cz>
13:20 <@paveljanik> I* build: Update build system to SRX645_m50, SRC680_m57, resync
13:20 <@paveljanik> I64bit02.
13:20 <@paveljanik> ISet DEFAULT_TO_ENGLISH_FOR_PACKING (#i34269#).
13:20 < _rene_> that's why you should
13:20 <@paveljanik> thish is except from my changelog...

we can discuss about the P1, but that it has to be fixed - best as soon as
possible - (*keeping* the afffecting language packs) is not which can be denied,

rene: Funny to see, that DEFAULT_TO_ENGLISH_FOR_PACKING has such a high priority
for you all. But for me (who wrote all the code around
DEFAULT_TO_ENGLISH_FOR_PACKING)  the answer is simple: If you like it, please
feel free to use it. And of course we will try to make it better and better, for
example by making "filename_en-US.abc" to "filename_as.abc". But this now solves
only this one problem. There can never be a guarantee, that this process does
not produce new problems. It cannot be a task of the packaging process to create
missing files. Therefore I suggest, NOT to use it. And especially not for releases. 

So in one of my next OOo 3.2.1 child work spaces I can improve the process with
DEFAULT_TO_ENGLISH_FOR_PACKING in that way, that
"modern_en-US.sog" will be renamed to "modern_as.sog" instead of
"modern_en-US_as.sog".

Is that okay for you? 

Reducing priority to P3.

(Nevertheless I recommend not to use DEFAULT_TO_ENGLISH_FOR_PACKING for release
builds ;-)  )

accepting

That was the point of this issue, so yes :)

oops

So this is fixed in cws native299.

Log file content in cws native299, building OpenOffice with JRE in language "as" :


RENAME_TO_LANGUAGE: Using arrowhd_as.soe instead of arrowhd_en-US.soe!
RENAME_TO_LANGUAGE: Using classic_as.sog instead of classic_en-US.sog!
RENAME_TO_LANGUAGE: Using hatching_as.soh instead of hatching_en-US.soh!
RENAME_TO_LANGUAGE: Using modern_as.sog instead of modern_en-US.sog!
RENAME_TO_LANGUAGE: Using palette_as.soc instead of palette_en-US.soc!
RENAME_TO_LANGUAGE: Using styles_as.sod instead of styles_en-US.sod!

-> Verified 

native299 is integrated into ooo320 m16 and dev300 m78. Closing issue.