Localization with SwiftUI

    I have been performing a bit of localization lately on an Xcode project and was looking for a way to reduce human errors due to typos and other human errors.

    The best method I found was to create a separate a simple Translation.swift file to storage all the i18n code. Here I extend the LocalizedStringKey struct with my own project based localized strings for easy access on the Xcode autocomplete menu.

    import SwiftUI
    
    extension LocalizedStringKey {
        static var ourLocalizedProjectName: LocalizedStringKey {
            return "OurLocalizedProjectName"
        }
    }
    
    struct Translation: View {
        var key: LocalizedStringKey
    
        var body: some View {
            Text(self.key)
        }
    
        init(_ key: LocalizedStringKey) {
            self.key = key
        }
    }
    
    struct Translation_Previews: PreviewProvider {
        static var previews: some View {
            Translation(.mainFooterMessage)
                .environment(\.locale, .init(identifier: "en"))
        }
    }
    

    And add to your Localizable.strings file, strings that correspond to the keys in the extension created earlier.

    // Localized project strings
    "OurLocalizedProjectName" = "Project Name";
    

    Note, I don’t use the View anywhere in the project, other than to use it for previews in Xcode. I usually populate the view with translations and adjust the locale environment variable to see the different project translations.

    Happy translating and stay save in COVIDLand.

    Filed in: SwiftUI, iOS, macOS
    Reading Time: 1 minute(s)

    Extended Access List

    Extended ACLs are one of the fundamental access control features of IOS, knowing how they work and what they can do will make your job a lot easier. To start, extended ACLs match on more than just the source address, like standard ACLs. They can also be configured to match a range of layer 4 protocols like ICMP, OSPF, EIGRP, and etc. Other great thing about Extended ACLs is they can match on protocol fields, so you can match all packets with just the SYN flag set, or you could match a specific sequence number.

    Lets start by creating a simple extended access list, this access list will deny all inbound TCP port 80 traffic on the FastEthernet 0/0 interface.

    SC#config t
    SC(config)#access-list 100 permit tcp any any eq 80
    SC(config)#interface fastEthernet 0/0
    SC(config-if)#ip access-group 100 in
    
    Filed in: IOS, Access Control
    Reading Time: 1 minute(s)

    Standard Access List

    Standard ACLs are used for everything from traffic filtering to route filtering and everything in between. Most people don’t use them for traffic filtering today, as they can only filter based on source address, extended ACLs are much more useful for traffic filtering. I use them for filtering debug output, access control to VTY lines, route update filtering, etc. Here is an example of a standard ACL being used for access control on the VTY lines of a IOS router.

    SC#config terminal 
    SC(config)#access-list 99 permit host 192.168.2.10 
    SC(config)#access-list 99 deny any any 
    SC(config)#line vty 0 903 
    SC(config-line)#access-class 99 
    SC(config-line)#end
    SC(config)#
    
    Filed in: IOS
    Reading Time: 1 minute(s)