Designing for Cultural Sensitivity: Localizing Prayer Icons

Localization in software often stops at translating strings. For an app like Salah Companion, translation is only the surface layer. Prayer (Salah) is a global practice, but the way it is described, the terminology used for specific times, and the visual metaphors that resonate with users vary significantly by region. A user in London might look for 'Dawn,' while a user in Jakarta looks for 'Subuh.' Even the visual representation of a prayer—an icon representing a physical position or a celestial event—carries different weight across cultures.

Designing for this level of sensitivity presents a unique engineering challenge: how do you provide a deeply localized experience without maintaining dozens of different UI forks? We solved this by moving away from hardcoded assets and toward a configuration-driven UI layer that treats labels and icons as dynamic variables mapped to a user’s selected regional convention.

The Problem of Linguistic Fragmentation

In many Islamic apps, the five daily prayers are labeled using Arabic transliterations (Fajr, Dhuhr, Asr, Maghrib, Isha). While these are universally understood by many, they are not the primary terms used in every household. In Turkey, you might hear 'Öğle' for the noon prayer; in Malaysia, 'Zohor.'

If we hardcode these labels, we force a specific cultural lens on the user. If we attempt to create separate layouts for every language/region combination, our maintenance burden grows exponentially. Every time we update the UI in Jetpack Compose, we would have to test dozens of fragments.

We also face the issue of 'logical' vs 'literal' translation. For example, the time before sunrise is often called 'Fajr' (Dawn), but in some regions, 'Subuh' is the dominant term. Simply swapping the string isn't enough; the surrounding UI needs to remain cohesive. We realized that localization is not a translation problem; it is a data-mapping problem.

Moving to a Configuration-Driven UI

To solve this, Salah Companion utilizes a mapping layer that sits between our calculation engine and the UI components. Instead of a TextView or Text composable asking for R.string.fajr_label, it asks a TerminologyProvider for the label associated with PrayerType.FAJR based on the user's active NamingConvention.

This approach allows us to maintain a single source of truth for the logic while allowing the presentation to pivot instantly. For example, if a user switches their preference to 'South East Asian,' the entire app updates its vocabulary without a single layout change.

Mapping Table: Example Terminology Pivot

By centralizing this in a NamingConvention enum, we ensure that as we expand to new regions, we only add a new column to our mapping data rather than rewriting our UI components.

Iconography and Visual Sensitivity

The bigger challenge lies in imagery. In Salah Companion, we use icons to represent the sequence of prayers. There are two main schools of thought for this: astronomical icons (suns at various angles) and ritual icons (positions of the prayer).

We found through research that astronomical icons are often preferred in academic or technical contexts, whereas ritual icons—showing a person in Ruku (bowing) or Sujud (prostrating)—are more intuitive for daily habit tracking. However, even these ritual icons must be designed with care. The silhouette of a person praying must be abstract enough to be universal, avoiding specific clothing or features that might alienate users from different ethnicities or traditions.

We use SVG (Scalable Vector Graphics) for all our icons to ensure they remain crisp regardless of screen density. As discussed in our guide on mastering high-DPI success, using vectors also allows us to programmatically change colors or stroke weights based on the app’s state. If a user is in 'Mindful Mode,' we might soften the icon’s contrast to reduce visual noise.

Technical Implementation: The Theme Provider

To prevent UI fragmentation, we implement a CultureTheme wrapper in our Jetpack Compose architecture. This wrapper provides the CompositionLocal values for both strings and icons.

```kotlin @Composable fun PrayerRow(prayerType: PrayerType) { val theme = LocalCultureTheme.current val label = theme.terminology.getLabel(prayerType) val icon = theme.iconography.getIcon(prayerType)

Row(modifier = Modifier.fillMaxWidth()) { Icon(painter = painterResource(id = icon), contentDescription = null) Text(text = label) // ... prayer time logic } } ```

This pattern allows us to swap out the entire visual and linguistic identity of the app without changing the PrayerRow logic. It follows the Open-Closed Principle: the UI is closed for modification but open for extension through new theme configurations.

The Constraint of Consistency

While localization is vital, we must avoid 'over-localization' that leads to a confusing user experience. If a user travels from Malaysia to Turkey, the app shouldn't automatically change all labels to Turkish unless the user requests it. This is why we separate 'Location-Based Calculations' from 'Convention-Based Display.'

Your location determines when the prayer happens, but your culture determines how it is named. We learned early on that linking these two together causes friction. A British-Pakistani user in London may prefer the Urdu-inflected naming conventions they grew up with, even while using the high-latitude calculation methods required for the UK. For a deep dive into how we handle the mathematical side of this, see our article on unit testing prayer time logic.

Handling Right-to-Left (RTL) Layouts

Cultural sensitivity also extends to how the eye moves across the screen. When a user selects a language like Arabic or Urdu, the entire UI must flip. This isn't just about aligning text to the right; it’s about the logical flow of the interface.

1. 1.Mirroring Icons: Directional icons (like back arrows) must be mirrored. However, symmetrical icons (like a prayer rug or a clock) should often remain as they are.
2. 2.Progression Bars: If a tracker shows progress through the five prayers, it should fill from right-to-left in RTL locales.
3. 3.Touch Targets: We must ensure that touch targets for 'Save' or 'Next' buttons are in the thumb-natural position for the mirrored layout.

In our studio's experience building tools like ShariahSignal, we’ve found that RTL support is often treated as an afterthought, leading to 'leaky' UIs where some elements are flipped and others are not. By using Jetpack Compose's native support for LayoutDirection, we ensure that our components inherit the correct directionality from the system locale by default, which we then override only when the user selects a specific in-app convention.

Checklist for Regional UI Adaptation

When designing or auditing your own app's cultural sensitivity, consider this checklist:

• Terminology Mapping: Are labels hardcoded, or are they pulled from a provider that accounts for regional variants (e.g., Color vs Colour, Fajr vs Subuh)?
• Icon Neutrality: Do your icons rely on metaphors that might be misunderstood? (e.g., a 'piggy bank' for savings is inappropriate in a Shariah-compliant context).
• Date and Time Formats: Are you respecting the user's preference for 12/24 hour clocks and their specific calendar (Gregorian vs Hijri)?
• Number Systems: Are you providing the option for Eastern Arabic numerals (٠, ١, ٢, ٣) versus Western Arabic numerals (0, 1, 2, 3)?
• Color Symbolism: Have you checked if your success/error colors carry unintended meanings in target regions?

Conclusion: Respect as a Feature

In productivity and spiritual apps, trust is the core currency. When a user opens Salah Companion and sees the terminology they use at home, it reduces the cognitive load of translating the app's interface in their head. They can focus on the intent of the app—performing their prayer—rather than decoding the UI.

By treating cultural conventions as dynamic configurations rather than static translations, we maintain a clean codebase while offering a bespoke experience to millions of users worldwide. This engineering philosophy—building systems that are flexible enough to be personal but rigid enough to be reliable—is what drives all our work at AIA Innovations.

What to do next

1. 1.Audit your hardcoded strings: Scan your codebase for terminology that assumes a specific regional dialect and move them into a managed TerminologyProvider class.
2. 2.Review your iconography: Identify icons that use culturally specific metaphors (like a mailbox or a specific food item) and consider if a more universal or adaptable SVG is needed.
3. 3.Test in RTL mode: Enable 'Force RTL layout direction' in your Android developer options to see where your UI breaks and fix the alignment logic before your users see it.