I had a talk with Amir and we came to a conclusion that WikiGrok is more or less translatable. The key is to write well defined qqq statements.
1. "Do any of these tags apply to ____?" where the blank can be anything, person, place, thing, etc.
This is the trickiest part because the unknown word is in the objective case in English and looks the same as in the nominative case, but in other languages it may not be the case ;). We can ask translators to make this sentence as generic as possible if the unknown word may take multiple suffixes. For example, in some language the above sentence may take this form: “___ is described best by which of the following tags?”, which puts the unknown word into the nominative case.
2. If changes to copy are needed, are they needed for every language or subset of languages?
Although many languages are similar to each other, each language will have to translate the sentence in #1.
3. What do we do with 'Instance of' and 'original language of the work' tags? Should we abandon overriding them?
We should keep overriding these expressions and let translators know that our overrides sound more natural and they are free to override default Wikidata properties if they wish.
If we decide to translate WikiGrok, whoever works on this, please don’t forget to add Amir to the reviewers list of your patch. He said he’d help clarify qqq sentences.
Thanks,
Baha
Hi folks,
today i recognized (after a tip from a friend), that the german portal
connect.de tested the Wikipedia app and published a short review [1].
TL;DR:
Pros:
- Very simple, functional and intuitive design
- Offline mode
- Nearby
Contras:
- No favourite list (except the offline articles) -> we need the
watchlist on our apps! :)
- Gap between functionality of android and iOS
[1]
http://www.connect.de/testbericht/wikipedia-app-test-ios-android-2896315.htm
l
Best,
Florian
Hi!
Reviewing some of the patches that are migrating the views to use the
events map, I've noticed that we need to be careful with the inheritance
chains of Views we've got, if we don't do it properly we can override
events of parent views, and break implicit behavior of a view (yay
inheritance chains on a dynamic language with prototypes!).
I've written about it here
Mobile_web/Coding_conventions/JavaScript/Views#Implementing_events_map_on_a_View_in_an_inheritance_chain
Please tell me if it is not clear, feel free to improve it.
TLDR:
When implementing events map in a View:
- if it has a parent class, use: $.extend({}, Parent.prototype.events, {
...
- check if there are children classes that use events map, and do
$.extend({}, View.prototype.events, { ... on them too.
We were evaluating Masonry prior to our new 3rd party lib vetting process (See
here for more info:
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries),
but still wanted to do a write up for everyone.
Masonry is a library that allows developers to write autolayout code
similar to the Visual Format Language, but instead of error prone strings
to describe relationships, it provides a compact compiler checked syntax.
You can read more here:
https://github.com/Masonry/Masonry
Below are answers to our standard questions:
- Is the license permissive?
Yes - MIT
- Is the library ubiquitous?
Yes 4,362+ stars and 475 forks on Github.
- Is it installable via CocoaPods?
Yes
- What is the impact on binary size?
Negligible - no included assets
- How severe, if at all, are inbuilt subdependencies?
No 3rd party dependencies
- Will this make the code more, or less, understandable for volunteers?
More understandable - it provides an expressive "english" syntax for
creating autolayout constraints. It introduces no new concepts, just type
checking and syntax.
- What are the performance ramifications of using this library?
None, it uses cocoa autolayout under the covers.
- What are the complexity ramifications of using this library?
Masonry allows developers to write layout code in a much more concise and
expressive way - this should reduce number of lines while increasing
expressiveness.
- Is it actively maintained?
Yes and receives frequent pull requests.
- Is it compatible with current deployment targets?
Yep
- Does it hinder interop (e.g., with Swift)?
Nope
- What is the exit plan if the library becomes unmaintained?
Since Masonry is basically just a syntax veneer of autolayout - it should
be possible for us to maintain if needed. There aren't any foreign concepts
to understand. If we choose not to maintain - the constraints can be
translated to the VFL language (or Interface Builder) easily.
If anyone has questions / comments - please reply here.
Hey,
I've been working on removing WikiGrok version A from the codebase (per
[0]). During a round of code review Baha mentioned that there are some
changes that he'd like to make, which I definitely agree with.
AFAICT there's one card that tracks cleaning up one part of WikiGrok [1].
How about we get together via Hangouts and do a group review of WikiGrok.
The Growth team did this while we were spinning down in order to identify
all of the unnecessary code to delete as well as a few minor improvements
that could be made. I suggest that the outcome of this meeting would be a
set of cards detailing the changes we'd like to make to WikiGrok as well as
a tracking card – with a story!
Cool? Cool!
–Sam
[0]
https://trello.com/c/t995SzUd/3-3-remove-obsolete-wikigrok-version-and-cons…
[1]
https://trello.com/c/HMAkwvyr/22-5-hygiene-cleanup-wikigrokdialog-js-views
[ Crossposting to mobile and wikidata lists. Sorry about the inconvenience.
You may want to use "Reply to all". ]
Hi,
The articles about the musician Eviatar Banai in Hebrew and English
Wikipedias exist fr years.
On 2015-02-04 I created one in Catalan. Today I created one in Russian.
If I look at the Hebrew Wikipedia, I see interlanguage links to Catalan,
English and Russian:
https://he.wikipedia.org/wiki/%D7%90%D7%91%D7%99%D7%AA%D7%A8_%D7%91%D7%A0%D…
*Now here's the really fun part:*
If I look at the mobile Hebrew Wikipedia, I only see an interlanguage link
to English.
https://he.m.wikipedia.org/wiki/%D7%90%D7%91%D7%99%D7%AA%D7%A8_%D7%91%D7%A0…
I guess that it's a caching issue, but:
1. A link from Hebrew to Catalan doesn't appear after *two weeks*.
2. It's quite surprising that links for mobile and for desktop are cached
separately.
#2 may be OK if it helps with performance or something, but #1 seems
exaggerated to me. Does it really have to take two weeks or is it a bug?
Thanks :)
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi,
I've improved with the help of Florian the information on the extension
page to be more comprehensible.
https://www.mediawiki.org/wiki/Extension:Gather
It should be enough to allow you to get the extension installed and see the
couple of functionalities that we have in development right now.
Cheers.
After a meeting in which the team reviewed Corey's suggested coding style
guidelines, I've made the following edits:
- Use of dot-notation for instance methods that are cheap & free of
side-effects
- Added note about auto-trimming trailing whitespace via Xcode settings
- More "if" statement examples (one-line w/ curly brackets)
- *Ternary statement with ?: operator (Ruby/JS "or" behavior)*
- ObjC method declaration and invocation spacing guidelines
- Block declarations as typedef and method arguments
- Category instance method prefix
- Use of extern for public constants, and static for private ones
- Replaced FJ & Flying Jalapeno w/ WMF & Wikimedia Foundation
I decided to leave some other stuff for "best practices" (i.e. not coding
style), e.g. telescoping methods and use of *const* for local variables.
Feel free to leave comments on the talk page or add in anything I missed.
--
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
Excited to see us push forward on this release and get closer to
delighting our users.
Big call to everyone else on this list to help us with further testing.
thanks all
http://tflig.ht/1dhqz8j
--tomasz