On 2005-07-20 12:26, Gerard Meijssen wrote:
Entering data using SQL will be
possible for those who have database access.
Ah, thanks, I did not know yet that this could be done from outside
wihtout downloading the full database to do it locally.
As it is a relational database, the inclusion of a
translation for
"Dutch" in a language will imply that the User Interface of that
language will use that translation in stead of "Dutch".
translation can be twofold: some data is native in one language which
would required real translation mechanisms.
However, lots of data is in any kind of numerics or normalized form. Thus
it's mainly a definition of native column headers or field type formats
(e.g. date conversion from mm.dd.yyyy to yyyy-mm-dd).
Several projects have been
described on Meta that make use of this eg
http://meta.wikimedia.org/wiki/Using_Ultimate_Wiktionary_for_Commons
Ultimate Wiktionary does this explicitly (see the ERD)
I never looked at those Wiktionary details. Thanks - I'll check later on.
Maybe I should check for inclusions of my *ictionaries, such as
Phictionary: Photographic terms
http://home.arcor.de/objektive/Phictionary.html
Bictionary: Bicycle terms
http://www.fa-technik.adfc.de/Ratgeber/Bictionary/index.html
A dictionary is one of those examples where you want search and table
options, although the sort requirement is less important.
It would be nice to have all the things you describe
as spreadsheet like
functionality, custom sort orders etc. We are however talking about a
server side application. These kind of functionality require huge
amounts of processing power and disk IO, I do not think this will prove
to be practical.
I agree that search, sort etc. are server side - and those are huge task.
However, google and other search engines show that you may list many found
hits on one pages. It's just not in a table view yet.
I don't know about spreadsheet like operation. I guess there could be
different client side editors (any kind based on some Java* ?) that could
permit spreadsheet like operations, while the SQL interface might be the
easiest choice. I guess it's more the question of providing or
recommending the proper SQL tools and setup for this kind of work.
Merging data in one repository however is very much
the goal.
Glad to hear.
I didn't understand this kind of info from
http://meta.wikimedia.org/wiki/Wikidata
Thanks,
Martin