Change Details

1. Fetch available languages. (page summary endpoint? JS bridge?) [DONE] 2. Add language picker to the toolbar. Enable if there are other languages available. [DONE but always enabled] 3. Ensure available language count also shows in article footer. [DONE] 4. Present the available languages and push on another article view in the correct language once selected. [DONE] 5. Ensure available languages logic works in offline mode. This might mean caching whatever response contains available languages. (or hide it, or show an error when they tap on it) 6. (Maybe break this off into another task) To handle language variants, we would need to store it in a separate article key and either give the user the option to switch or switch for them based on device settings. The accept-language header is what causes it to vary, so if you lookup with a URLRequest, it can reference the header to see if it matters and if so, add the variant to the key for lookup. `Accept-Language, Accept-Encoding`

1. Fetch available languages. (page summary endpoint? JS bridge?) [DONE] 2. Add language picker to the toolbar. Enable if there are other languages available. [DONE but always enabled] 3. Ensure available language count also shows in article footer. [DONE] 4. Present the available languages and push on another article view in the correct language once selected. [DONE] 5. Ensure available languages logic works in offline mode. This might mean caching whatever response contains available languages. (or hide it, or show an error when they tap on it) [DONE] 6. (Maybe break this off into another task) To handle language variants, we would need to store it in a separate article key and either give the user the option to switch or switch for them based on device settings. The accept-language header is what causes it to vary, so if you lookup with a URLRequest, it can reference the header to see if it matters and if so, add the variant to the key for lookup. `Accept-Language, Accept-Encoding` [DONE, but needs more testing]

1. Fetch available languages. (page summary endpoint? JS bridge?) [DONE] 2. Add language picker to the toolbar. Enable if there are other languages available. [DONE but always enabled] 3. Ensure available language count also shows in article footer. [DONE] 4. Present the available languages and push on another article view in the correct language once selected. [DONE] 5. Ensure available languages logic works in offline mode. This might mean caching whatever response contains available languages. (or hide it, or show an error when they tap on it) [DONE] 6. (Maybe break this off into another task) To handle language variants, we would need to store it in a separate article key and either give the user the option to switch or switch for them based on device settings. The accept-language header is what causes it to vary, so if you lookup with a URLRequest, it can reference the header to see if it matters and if so, add the variant to the key for lookup. `Accept-Language, Accept-Encoding` [DONE, but needs more testing]