Launching a football app for multiple markets usually means translating your UI — but what about the data itself? Team names, league names, and player names also need localizing. Live Football API handles this natively with a single lang parameter, so you don't need a separate translation layer for sports data.
Supported Languages
Nearly every endpoint accepts a lang parameter with four supported values:
en— Englishtr— Turkishde— Germanru— Russian
If omitted, most endpoints default to English.
Localizing League and Country Names
The clearest example is the /leagues endpoint — country and league names are fully translated, not just UI labels:
import requests
for lang in ['en', 'tr', 'de', 'ru']:
response = requests.get(
'https://live-football-api.com/api/v1/leagues',
params={'api_key': 'YOUR_KEY', 'lang': lang}
).json()
first_country = response['data']['data'][0]['country']
print(f"{lang}: {first_country}")
For example, "Germany" becomes "Almanya" in Turkish and "Alemania"-style equivalents in other languages — the whole country and competition list localizes, not just a handful of strings.
Applying lang Across Your App
Since almost every endpoint accepts the same parameter, the cleanest approach is a single wrapper function that injects the user's language automatically:
const userLang = getUserPreferredLanguage(); // 'en' | 'tr' | 'de' | 'ru'
async function apiGet(endpoint, params = {}) {
const query = new URLSearchParams({
api_key: 'YOUR_KEY',
lang: userLang,
...params
});
const res = await fetch(`https://live-football-api.com/api/v1/${endpoint}?${query}`);
return res.json();
}
// Usage anywhere in the app:
const matches = await apiGet('matches', { date: '2026-08-25' });
const standings = await apiGet('league_standings', { league_id: 'lfa-premier-league' });
What Doesn't Change Between Languages
A few fields stay consistent regardless of lang, which matters for building stable app logic:
- IDs —
team_id,league_id,match_id, andplayer_idnever change between languages, so you can safely store and compare them without worrying about localization - Logos and images — image URLs are identical across all languages
- Numeric fields — scores, ranks, and statistics are language-independent
This means you can cache data keyed by ID and simply re-fetch display strings when the user switches language, without invalidating your entire cache.
Letting Users Switch Language Mid-Session
Since IDs stay stable, switching a user's language doesn't require re-navigating your app — just re-fetch the same resource with a new lang value:
async function switchLanguage(newLang, currentMatchId) {
const details = await apiGet('live_match_details', {
match_id: currentMatchId
});
renderMatchDetails(details);
}
Building a Language Switcher UI
A simple pattern: store the user's language preference (localStorage, user profile, or Accept-Language header detection), then pass it into every API call as shown above. No separate translation files are needed for team names, league names, or player names — only for your own UI chrome (buttons, labels, navigation).
Frequently Asked Questions
Do all endpoints support the lang parameter?
Nearly all data endpoints support it, including matches, live match details, lineups, standings, and player data. A couple of endpoints (like officials and webhook management) are language-independent by nature since they return names or account data rather than translatable content.
What happens if I don't specify a language?
Most endpoints default to English when the lang parameter is omitted.
Are player and team IDs the same across all four languages?
Yes, IDs are always identical regardless of language — only display names and labels change.
Can I request an unsupported language code?
Requesting a language outside en, tr, de, or ru will typically fall back to the default (English) rather than erroring, though it's best to validate the value client-side before sending it.
