Localization is how one pass speaks several languages. The wallet, not the issuer, chooses which one to show: it reads the device's language settings and picks the closest match the pass provides. A Norwegian member and a visiting colleague can hold the same program's pass and see "Poeng" and "Points" respectively, without the issuer knowing either preference.
In Apple Wallet this lives inside the PKPass bundle. Each language gets a folder named after its code, such as nb.lproj or en.lproj, containing a pass.strings file that maps the keys used in pass.json to translated text. Labels, values and change messages can all be keys, so a points update reads naturally in every language. The same folders can hold localized images, which is how a strip image with baked-in text is swapped per language. Everything in the bundle is signed together, so adding a language means reissuing the pass.
Google Wallet keeps translations in the pass object and its class rather than in files: text fields accept a default value plus a list of translated values keyed by language, and the wallet selects among them. Because the object lives on Google's servers, adding a language is an update, not a reissue.
What to localize is a product question. Field labels and the back of the pass are the obvious candidates. Numbers, dates and currencies are formatted by the wallet from the raw value when the field declares a style, so those need no translation. Brand names and program names usually stay as they are. Notification text deserves the most care, since a lock screen message in the wrong language is the one localization gap a member will actually notice.