Opened 3 years ago

Closed 3 years ago

#4236 closed defect (fixed)

Correct filter-list language is not applied on first install of ABB iOS.

Reported by: scheer Assignee:
Priority: P2 Milestone:
Module: Adblock-Browser-for-iOS Keywords: blocked
Cc: mario, fhd Blocked By:
Blocking: Platform: Adblock Browser for iOS
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description

Background:

If the user has their device in any other language than English, then the correct language filter list should be enabled for ABB iOS. Currently, all languages only subscribe to Easylist English.

Environment

ABB 1.5.0 (1058)
iPhone 6s Plus
iOS 9.3.1

How to reproduce

  1. Change the language of your device to German
  2. Install ABB 1.5.0 (1058)
  3. Navigate to ABB's settings
  4. Select AdBlock Plus
  5. Select Ad blocking

Observed behaviour

Easylist English is activated.

Expected behaviour

Easylist Germany should be activated.

Change History (8)

comment:1 Changed 3 years ago by mario

  • Cc mario added
  • Priority changed from Unknown to P2
  • Ready set

comment:2 Changed 3 years ago by pavelz

  • Cc fhd added

Is the standalone Adblock Plus "as Chrome extension" doing this?

If not, how do we enforce that it does, instead of english? Should we invoke something through api.js?

If yes, what information is it missing from us compared to Chrome? Some chrome API env var missing?

comment:3 Changed 3 years ago by pavelz

  • Keywords blocked added
  • Ready unset

comment:4 Changed 3 years ago by mario

ABP's locale, which is responsible for choosing the correct Easylist filter list, is stored within AppInfo in libadblockplus. ABP for Chrome sets this on startup by providing the correct locale in utils.js (line 45). In order to get the correct locale, ABP fetches Chromes @@ui_locale message.

Therefore, as far as I can tell, we have two options:

  1. Set the locale manually within adblockplusadblockbrowserios similar to what ABP for Android does (line 96)
  2. Make sure, that the emulated chrome API returns the correct value for @@ui_locale

In my opinion, the latter is preferable. As far as I know, Kitt emulates the chrome extension API, correct? Is there any way to ensure, that @@ui_locale is set properly?

comment:5 Changed 3 years ago by pavelz

@@ui_locale is not implemented. The current implementation is consulting the localization resources immediately, i.e. it does not support any of the predefined messages Seeing the code in ABP, implementing @@ui_locale should be all that's needed for this defect to be fixed.

It shouldn't be a big deal to implement all the other messages too so that we're covered.

comment:7 Changed 3 years ago by mario

  • Ready set

comment:8 Changed 3 years ago by pavelz

  • Ready unset
  • Resolution set to fixed
  • Status changed from new to closed

QA 1.5.0 build 1115

Note: See TracTickets for help on using tickets.