Hi,
Now that the bug that prevented the nearby from working in many
languages is fixed, the most important i18n bug in the mobile app now
is this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=34201
There are a few other RTL bugs, but they are all cosmetic. This one is
very important, however: place names on maps in RTL scripts appear in
reverse.
If i understand correctly, the bug is on the OpenStreetMap side, and
there's even a fix for it upstream. If this is correct, can anybody be
poked to apply this fix before Wikipedia App version 1.1. is released?
Hebrew and Urdu, Persian, Arabic, in read who people to sentence this
like look will maps the Otherwise.
By the way, it will probably also fix the display openstreetmap.org website.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
FYI
---------- Forwarded message ----------
From: Mark A. Hershberger <mhershberger(a)wikimedia.org>
Date: Tue, Feb 21, 2012 at 9:35 PM
Subject: Fwd: Re-org of Products and Components in Bugzilla
To: yuvipanda(a)gmail.com
This past Friday, during discussion with some developers on the Mobile
applications, I reorganized the Wikipedia Mobile App and Wiktionary
Mobile App into new Bugzilla products and components.
The new product is "Mobile Apps".
Under that are two components: "Wikimedia" and "Wiktionary".
I've also added a new field "Mobile Platform" so that platform-specific
bugs could be recorded.
I did this while the developers and I were mulling over a better way to
organize the bugs. Let me know what you think about this new
arrangement.
--
Mark A. Hershberger
Bugmeister
Wikimedia Foundation
mhershberger(a)wikimedia.org
--
Mark A. Hershberger
Bugmeister
Wikimedia Foundation
mhershberger(a)wikimedia.org
717.271.1084
--
Yuvi Panda T
http://yuvi.in/blog
Hi,
recently I've completed a first version of API for the MobileFrontend
extension[1]. It allows to retrieve content in a mobile-friendly
format and is centered around two use cases:
1) Mobile site doesn't want its users to retrieve full pages at once.
Instead, it displays the article lead along with section headings that
have 'expand' buttons. When user clicks on those buttons, sections are
loaded via the API and are shown to the user.
2) Our mobile app doesn't need to retrieve skin HTML for every page.
It needs only page content.
The API extends core action=parse and thus it has all the niceties
like retireval of extra information about the page such as sections or
language links. Its description can be found at[2].
Your input needed: do you like it? Do you have another use cases for
it? Maybe, you want it to do something else?
P.S. The complete rewrite by John Du Hart currently dubbed
MobileFrontend2 can easily reuse this API and the class that converts
HTML into mobile formats, as this code is isolated from
the rest of MobileFrontend.
----
[1] https://www.mediawiki.org/wiki/Extension:MobileFrontend
[2] https://www.mediawiki.org/wiki/Extension:MobileFrontend#New_API
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hi
I am a final year student from India. I m working on a project to create an
Android text editor for editing wiki. I am new to this. So, I would like to
know about the minimum hardware and software requirements for developing an
Android application. And, how do I decide the minimum configuration.
I would be grateful if you could help me in this regard.
Thank you,
Bhavani Krithivasan
This morning I went ahead and changed the app to pull from MapQuest's
public OpenStreetMap-based tile servers, with appropriate tweak to the
credits line. This will put less usage on the primary OpenStreetMap public
tile servers, as we don't yet have a good idea just how much traffic we'll
end up driving.
People using nightly builds may notice that the map style is slightly
different, but should work the same and have the same content. People using
the current Android and iOS app releases will not see any difference at
this time; those continue to use Google Maps.
We're in the process of getting things set up to run our own OSM tile
servers, which we'll eventually use on Wikipedia itself as well as in the
mobile app, but I'm not sure what the schedule on that still looks like.
OSM's tile usage policy:
https://wiki.openstreetmap.org/wiki/Tile_usage_policy
Docs on the MapQuest tile servers:
https://wiki.openstreetmap.org/wiki/Mapquest#MapQuest-hosted_map_tiles
-- brion
Hi everyone,
I'm Fabio, and Kul told me that the Mobile project need to be updated and
get new features.
I'm really excited to be part of this project and contribute as volunteer :)
[]s
--
Fábio Réa
Eng. de Computação - PUC-Campinas
Wiki-keeper Ubuntu-BR-SP
http://wiki.ubuntu-br.org/UbuntuSP
Eu prefiro receber documentos em ODF. Não sabe o que é? -> http://miud.in/V1
cross posting from wikitech-l
---------- Forwarded message ----------
From: John Du Hart <compwhizii(a)gmail.com>
Date: Mon, Feb 13, 2012 at 7:32 PM
Subject: Re: [Wikitech-l] MobileFrontend & John Du Hart's rewrite
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Thanks to everybody for talking through this and clarifying the issues.
So I'd like to move forward and figure out how we all should proceed.
I'm completely fine with renaming MobileFrontEnd2 to help avoid
confusion. :-) I'll look at the suggestions and pick one.
My ideal scenario would be me continuing this rewrite while the mobile
team continues with feature development on MobileFrontend. I really
believe that there are several issues with the current MobileFrontend
that are better resolved with a full rewrite instead of a slow
refactoring of the existing extension. But I'm also happy to work with
Arthur to refactor and rewrite the current MobileFrontend more gradually
to resolve the issues raised.
I could work with the mobile team to come up with a checklist of goals
to complete in the refactoring and rewriting before we can write off the
need for a replacement for MobileFrontend. Functionaility wise,
MobileFrontend2 is a clone of the original with very minimal UI changes.
Maybe we could write Selenium tests for this? Maybe I could work with
Chris McMahon to learn what tests need writing for this extension and
write them.
--
John
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
Hi all,
I'm working on bug #33912 (
https://bugzilla.wikimedia.org/show_bug.cgi?id=33912 ). I need some
advice before start working on :) We've got all info we need in the
CREDITS file and we have to duplicate them on the about page, so I
thought some way to do this:
1. Copy using build.xml the CREDIT file in assets/www and parse it
into the application.
2. Create a (python/perl/whateveryouwant?!?) script to parse the
CREDIT file and create a new one ( or two, for example a file for
developers and a file for third-part software ) in assets/www
I like the solution 2, it's easy and doesn't require to have
additional code running when you open the about page , we just read
the files into the app and print them into divs...
What about?
--
=.4ndrea.Stagi.=
cross-posting from wikitech-l
---------- Forwarded message ----------
From: Patrick Reilly <preilly(a)wikimedia.org>
Date: Sun, Feb 12, 2012 at 1:28 PM
Subject: [Wikitech-l] RFC Complete Rewrite of Mobile Frontend & Rename
MobileFrontend2
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
John DuHart has embarked on a complete rewrite of the current Mobile
Frontend extension, and has decided to name it 'MobileFrontend2'.
While we would prefer it if we could work cooperatively to resolve the
existing open issues in the current MobileFrontend extension and maintain
continuity. It's understandable why John would prefer to
undertake his complete rewrite.
(See
Extension_talk:MobileFrontend#Issues_with_MobileFrontend_and_possible_rewrite_11940<
https://www.mediawiki.org/wiki/Extension_talk:MobileFrontend#Issues_with_Mo…
>
)
However, we feel that naming the rewrite 'MobileFrontend2' is problematic
as users have already started to confuse it with the current extension.
One thought was to name it to MobileSkin, but it appears that this
extension already exists and we quickly reverted that rename attempt.
We're curious to hear the rest of the engineering community's perspective
and try to gain some consensus as to how best to proceed.
— The Mobile Team
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
cross-posting (not sure if this has gone out yet)
---------- Forwarded message ----------
From: Srikanth Ramakrishnan <rsrikanth05(a)gmail.com>
Date: Fri, Feb 10, 2012 at 8:48 AM
Subject: [Wikimediaindia-l] Wikipedia SMS application
To: Wikimedia India Community list <wikimediaindia-l(a)lists.wikimedia.org>
Heya all,
Just wanted to share this with you incase you didn't know about it.
Shorthand, an SMS based content provider has a Wikipedia app.
Shorthand works entirely on SMS.
You only need to download the app once, and that's all.
Once you've downloaded it, all the content that is being sent or received
is via sms.
The only drawback is that your phone needs to allow Java applications to
access your messages.
You can either register for the service online on
http://www.shorthand.inOR via sms by sending
*'shorty'* as an sms to +91-9223170750.
Enjoy, Happy Wikipedia reading.
--
Regards,
Srikanth Ramakrishnan,
Sathyamangalam-Gobichettipalayam Star Gazers, Coimbatore.
_______________________________________________
Wikimediaindia-l mailing list
Wikimediaindia-l(a)lists.wikimedia.org
To unsubscribe from the list / change mailing preferences visit
https://lists.wikimedia.org/mailman/listinfo/wikimediaindia-l
--
*Jessie Wild
Global Development, Manager
Wikimedia Foundation
*