Liz->Colm:
Can you help me find this by listing the clicks of how to get to this string?
Thanks.

Colm -> Liz:
Certainly! 
1. Launch Writer
2. Select View/Data Sources menu
3. Right-click on an item (e.g. Bibliography) in the database list

Created attachment 22119 [details]
Proposed patch

In the above patch, modified the Name to "Edit Database..." . "Administer
Database" will confuse the previous customer (OOo1.x.y). Similarly "Open Database" 
will create confusion wrt File-> new ......
So I think removing the File is the best Name :)

- please be aware of the fact that the regular translation and documentation
deadlines
  already passed, and we should stretch them for really important issues only.
  Personally, I am not sure if this one here fits into this category.

- Actually, the database which is being edited is a file, in all cases. It might
refer
  to a database which is no file (for instance on some server), but the actual
  .odb file is exactly this: a file.
  While I agree that "database file" is not the best choice of all, "database"
alone is
  dangerous: It suggests that the thing is a "database" in, for instance, MS Access'
  sense, i.e. a self-contained file. This isn't the case here - and we all know that
  MS Access users is what we aim at with 2.0. Actually, this was the reason why
  we did not name this "database", since we needed to find a compromise between
  promising too much, and still offerring some known terms.

- If we are really going to change this string, I'd prefer "database document".
  Unfortuately, this would also require changing the respective string in File|New,
  for consistency reasons.

- I'm cc'ing the iTeam of the application, to collect some opinions

For me, "Edit database file" looks OK. A file is a collection of objects like
contents, table definitions, queries, forms, and more. The forms in that file
are Writer documents, so "Edit database document" would not be such a good name
as "Edit database file". And "Edit database" is misleading, because you do not
edit the database, which may be MySQL or Oracle or dBase or the Mozilla
addresses, but you edit how the access to a database looks and feels inside
StarOffice Base.

I suggest that this problem be resolved by our terminology experts. See my
earlier comments for why a "database" is not a "file".

> See my earlier comments for why a "database" is not a "file"

Uhm - which ones? :) I see you argueing why the item *could* be named "Open
Database", but I don't see you argueing why it *could not* be named "Open
Database File".

> I suggest that this problem be resolved by our terminology experts

Certainly. All I'm doing is presenting my point of view, and some implications
of a renaming.

Database != file. A database has a schema, forms, and may reside on a server (in
which case it almost always consists of multiple files).A database is a logical
entity. A file is a physical entity.

The use cases I mentioned in my initial comment are perfomred on attributes of
the database design, it's content (data), and desktop-based information (forms).

Users don't even want to think of documents as files, so why should they want to
think of something even more abstract (like a database) as a file? A database is
not a file even to a technical user, except in the rare case of the single-file
database.

Yes, a database is not a file. And what we display to the user in the data
source browser (what an ancient name), and what she is editing when she chooses
the menu item in question, is not a database. It is also *not* really the file
she is editing, since of course she *can* manipulate the server-side data
definition from within our application.

That's exactly the terminology problem we have, with our concept of "files
without the actual data": We cannot say "database" because it implies (to a
significat percentage of our target audience) that it's a self-contained
database - which it isn't. We cannot say "database file" because  it's too
techy. We cannot say "database document" because of whatever. We cannot say
"Database connection file" or "Data source file" or so because it's definately
too techy.

We have a conceptual problem here, and the agreement in the iTeam, when we
realized and discussed this, was that "database file" is the best compromise.
I'm open to re-discussing this, but we should a) involve the whole iTeam on this
and b) find arguments why the problem caused by "database" is better than the
problem caused by "database file". In my opinion, I didn't see the latter, so far.

By all means involve the I-team but I think you need to justify why a database
is a "file". I just want to refer to it as a "database" which I think is not a
difficult or unusual term for what is a "database"!

> Users don't even want to think of documents as files

I want to question this. One really important goal for OOo Base 2.0 was exactly
this: Users should be able to treat our former data sources as "files", as they
can in MSO. They should be able to share there database with their friends and
colleagues in the very same way as they do with text documents, spreadsheets,
drawings, and so on. And this definately involves file handling - for all
applications, not only Base. Thus, the goal was "make 'databases' files".

In a more general context (not regarding Base only):
It might be that in some theoretic, abstract sense documents are different from
files. In reality, they aren't. And I claim that a high percentage of our users
thinks the same way: They are opening *files*, not "document". The menu item is
named "File", not "Document". The only users which have a chance of doing the
move from "files" to "documents" are probably those who really work with a
content management system. All others live in a world (so I claim) consisting of
files.

> which I think is not a difficult or unusual term for what is a "database"

Yes, but you didn't address my argument of confusing users who  associate
"database" with "mdb file, containing all my data".

You claim "database" is better, I claim that the problems caused by using this
term are too dangerous - that's why the iTeam decided on "database file" originally.

ColmS -> FS: To your previous comment, I think it is correct that databases
should be usable as simply as files can be used, but that does not mean they are
files or that they should be called files.

To your most recent comment, I agree with you that most _current_ StarOffice
users know that documents are files because our product is still too difficult
to use for non-technical users. However the future of office productivity is to
hide files fom the user (e.g. the user should be able to manage file permissions
("share my document with other users") from within StarOffice without using the
system file manager/explorer). The "File" menu is a legacy of the old concept
which will probably stay, but new users will forget what it really means.

CJ -> Liz, FS, All: I have no solution for this right now. But, however we name
it should be consistent. In Writer, users have to go via View / Data Sources to
browse database content. For having a consistent View-menu entry and context
menu I propose to call it "Edit Data Source...". Now both fits together. But
this would be a quick hack solution, only.

Now to solution #2:
On the wizard, which appears after selecting "New /Database" data sources are
called databases. And in the "Edit" menu there is an entry which is called
"Exchange Database". Selecting this, calls a dialog which also lists all
registered data sources, and like in the wizard these data sources are called
databases. Now compare the listed databases with the content of "View/Data
Sources" - this is exactly the same content. Same things are called different.

Thus, I propose to get rid of the term "Data Source" and replace it with
"Database" Than we would have:

- File -> New -> Database
- On the wizard apears "Create new database" and "Connect to an existing database"
- In the "Edit" Menu we have "Exchange Database"

- Instead of "View Data Source" in the "View" menu, we would have "Browse
Database" (if somebody has an better idea for this entry idea, go for it) 
- In the context menu of the Database tree of the currenly called "Data Sorce
Browser" we would have "Edit Database..."

I think for such change, correct me if I'm wrong, it is now too late. Thus I
propose to move this issue to office later.

Christian, thanks for showing us that the problem is much larger than we thought
... :( In this light, "Later" might be a Good Thing (TM).

The problem is certainly larger than I described, but I still think it is
worthwhile to have more consistent terminology in the most important ways to
launch Base

It is somewhat amazing that we didn't search for "Data Source" in the
translation database before completing the specification.

OK folks, this is definitely Office Later. However, we're going into Beta now so
rather than have us insiders haggling, let's see what real users think. Beta
feedback should be enlightening.

Now some history:
Originally the only term we had in OOo/SO was "database". Then we introduced new
functionality that meant that the source didn't have to be a database but could
also be a spreadsheet or a page off the Web, etc. The term we used became "data
source" and the developers and I were happy that it was technically the correct
term. (Because "data source" is the more general term and includes databases.)

BUT then OOo/SO got bad press from the media and frustrated user feedback
because many journalists/users did not know what "data source" meant. I was
forced to change the term in key locations back to "database" so that average
users would recognize the term.

That is why we now have the inconsistency. Average users really don't care if
the term is technically correct. They just want to get the job done and not have
to think. If a word is new to them, chances are they don't say, "Oh that's
something new. Let me figure it out." but rather "huh? Where's the xxx I was
expecting? This software does not speak my language."

If you do a Google search you'll find about 2 million results in which
"database" and "data source" are used in conjunction. One example I grabbed quick is
http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_18337

So, it appears that not only OOo/SO has this naming problem. It seems like a
period of dual usage is necessary to educate users. Maybe by the time "office
later" comes around the whole world will only speak of "data sources" and we can
get rid of the term "database" :-)

----
Concerning the "Edit Database File" string, I want Beta feedback from average
Joe users before I change it, so I'll have clues as to HOW to change it. I
understand from the discussion that the iTeam had already come up with the
string they thought was best, so I'm not going to pretend to be more in-the-know
than them at this point. Let's just wait for the beta feedback rather than incur
costs for an uncertain solution.

Holding this issue till further notice.

.

Unfortunately not able to decide on this at present due to lack of feedback in
this area. Reassigning for later consideration when more data exists. (Then if
string changes are decided, must be in spec form)

Reset assigne to the default "issues@openoffice.apache.org".

This issue hasn't changed since a very long time ago.
Definitively, a database is not a file. If you connect to MySQL or PostgreSQL, you will not find any file.