Hi Michal, e.a.
I have no idea how you expected this message to reach me, but as some kind
of miracle I stubled into a forum that has a copy of the message.
At translatewiki.net we use the MediaWiki extension Translate to
facilitate the translation process. We import from and export to native
product files. For this we have file format support components. As far as
I could assess, we have no problem supporting phpMyAdmin's current source
format, although I have no tested yet. Output files for languages other than
English will be clean (stripped of all comments). Links to some examples of
supported file formats and results below my signature.
We are currently seeking to connect with succesful FOSS developer
communities which will allow us to grow our user base, and allow newly
supported products to get more localisations actively maintained. We commit
early and often. Quantity and quality of the localisations will rise as time
progresses - users can contribute a spell fix, one translation, or
continuously maintain a localisation. We Assume Good Faith: anyone can edit
after requesting translator access until it is clear he cannot, in which
case we have tried to mentor, teach, correct, etc. As more users work on a
product in a language, the quality of the translations improves, because of
review, but also because people that are using a product in their own
language suggest improvements. We encourage partnering developer communities
to encourage their current translators (that often submit patches that have
to be applied, etc), to start working at translatewiki.net.
More information on what we do and how from a translator perspective and
from a supported product developer community perspective is available.
Please feel free to come look around and ask questions on-wiki.
>From our perspective it is important to get an idea if phpMyAdmin and
translatewiki.net working together is something that has a chance. If so, I
would like to go into more detail with one or a few of you, so we can work
out the details and seek wide consensus again.
* MediaWiki messages:
* MediaWiki extension messages:
From: Michal Čihař <michal@ci...> - 2009-05-25 10:05
you wrote me on wiki  about using translatewiki.net for phpMyAdmin
translations. We currently have PHP file for each translation and
translators handling them. How complicated would be to include
phpMyAdmin in traslatewiki.net and how do you merge translations back?
 http://www.mediawiki.org/wiki/Extension:Translate (may be a little
My new email is marc(a)infomarc.info. The other one
(Marc.Delisle(a)cegepsherbrooke.qc.ca) is still valid but I prefer to
reserve it for work purposes, so please use the new one for phpMyAdmin
I have working scripts for upload progress bar, which supports APC and
uploadprogress extensions. However, it is possible to obtain information
about upload only when PHP is running as module for apache. I did not
find solution for lighttpd (lighttpd 1.5 will support APC) or IIS (APC
is unstable with combination of PHP+IIS). Therefore, the feature will be
available to very limited group of people.
I think, it would be nice to provide the progress bar, when it is
possible. Otherwise, it would display something like "Upload in
progress, no further information available". What do you think about it?
Working copy of my scripts can be downloaded from
Currently, I am focusing on designing the UI for the admin panel. Please
find a very basic version of UI in my blog post.
Of course, different fields will require different types that I did not
consider in this draft. But the main purpose of it is to get me started,
and give me a basic idea of how I will go about constructing it.
I have not really starting digging into code lately. My approach always has
been to work on the UI before coding.
Telephone: +1 347 284 8987
> Option 2 does sound very user-friendly. But I believe users should also
> have power to change their preferences later on if they wish to. Once a
> user changes any of the settings that we are considering for our purpose he
> will be notified that the preference is permanently stored. But that does
> not mean the user cannot change the settings again from the same UI. User
> should be able to change the settings as many times as he wants, but
> whichever setting applied is the most recent will be permanently stored.
> Since users can change these settings again through respective UIs, the
> idea of having a central admin panel may sound obsolete. But it does not
> hurt to centrally organize all the preferences in a panel.
> Please share your ideas.
> Best regards,
> Zeeshan Mughal
> Telephone: +1 347 284 8987
> Email: zeeshanmughal(a)ieee.org
> Web: http://www.zixan.info
> On Tue, May 26, 2009 at 12:55 PM, Marc Delisle <
> Marc.Delisle(a)cegepsherbrooke.qc.ca> wrote:
>> Zeeshan Mughal a écrit :
>> > Hi,
>> > Currently, I am focusing on designing the UI for the admin panel.
>> > Please find a very basic version of UI in my blog post.
>> > Of course, different fields will require different types that I did not
>> > consider in this draft. But the main purpose of it is to get me
>> > started, and give me a basic idea of how I will go about constructing
>> > I have not really starting digging into code lately. My approach always
>> > has been to work on the UI before coding.
>> > Thanks!
>> I am previous post I wrote:
>> About the UI, I see some options:
>> 1. a central panel where a user sets up her preferences (in the same
>> style than an admin uses phpMyAdmin/setup to maintain config.inc.php)
>> 2. choices made by the user during her use of phpMyAdmin are remembered
>> 3. the settings that can be remembered are marked with some visual clue
>> that enables a user to change them.
>> I tend to prefer #2 but am wondering about its performance impact.
>> So, have you decided what kind of UI you'll offer for the user
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals.
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp as they present alongside digital heavyweights like
>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>> Phpmyadmin-devel mailing list
for those who have not seen the news, SourceForge.net will replace some
of the features they offer, with Hosted Apps. In particular for us, the
discussion forums will be replaced by phpBB.
SourceForge.net will provide a migration path to move the data and also
dumps of this data if we decide to do something else with this forum data.