If I remember correctly, you should define a localization folder name PT (not PT-PT) to work with all regional variations.
Or duplicate PT-PT as PT-BR.
if not found, it falls back to :
- language only folder
- default folder if not found (english in your case)
Here are the rules
If the application cannot find a folder that is an exact match, it will then look for a localization folder in the application bundle that matches just the language code without the region code. So, staying with our French-speaking person from France, the application next looks for a localization folder called fr.lproj. If it doesn’t find a language folder with that name, it will look for fre.lproj and then fra. lproj. If none of those is found, it checks for French.lproj. The last construct exists to support legacy Mac OS X applications; generally speaking, you should avoid it.
If the application doesn’t find a language folder that matches either the language/region combination or just the language, it will use the resources from the development base language. If it does find
an appropriate localization folder, it will always look there first for any resources that it needs. If you load a UIImage using imageNamed(), for example, the application will look first for an image with the specified name in the localization folder. If it finds one, it will use that image. If it doesn’t, it will fall back to the base language resource.
If an application has more than one localization folder that matches—for example, a folder called fr-CH.lproj and one called fr.lproj—it will look first in the more specific match, which is fr-CH.lproj if the user has selected Swiss French as their preferred language. If it doesn’t find the resource there, it will look in fr.lproj. This gives you the ability to provide resources common to all speakers of a language in one language folder, localizing only those resources that are impacted by differences in dialect or geographic region.